


        Anwendung                 - 221 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        _2._2._4._1_2.  EEEEiiiinnnnddddeeeeuuuuttttiiiiggggeeee SSSScccchhhhlllluuuu""""sssssssseeeellll

        Bei der Wahl des Schlu"ssels ( kkkkeeeeyyyyeeeedddd ddddoooommmmaaaaiiiinnnn ) einer  Relation
        ist   es   wu"nschenswert,   weitgehende   Eindeutigkeit   zu
        erreichen.  Beispielsweise treten bei Personalnummern  keine
        doppelten  Nummern  auf,  wa"hrend bei solchen Begriffen, wie
        "Farbe" nur einige wenige verschiedene Werte  und  manchmal,
        wie  bei  "Geschlecht"  bekanntermassen  nur zwei Werte auf-
        treten ko"nnen.

        Wenn eine Relation auf  die  Doma"ne  "geschlecht"  via  hhhhaaaasssshhhh
        geschlu"sselt wird, ko"nnen sie erwarten, dass alle ma"nnlichen
        Objekte auf einer Haupt-Seite  und  dazugeho"rigen  U"berlauf-
        Seiten  untergebracht  werden,  ebenso auch alle weiblichen.
        Mit einer hhhhaaaasssshhhh -Relation gibt es keine Lo"sung  dieses  Prob-
        lems.  Es muss ein Kompromiss zwischen den in der Qualifika-
        tion am ha"ufigsten verwendeten Schlu"sseln und der Eindeutig-
        keit der Schlu"sselwerte gefunden werden.

        Da der Vorteil der iiiissssaaaammmm  -Struktur  solange  genutzt  werden
        kann,  als  zumindest  der  erste Schlu"ssel vorgegeben wird,
        ko"nnen  unter  Umsta"nden  weitere  Doma"nen   zum   Schlu"ssel
        hinzugefu"gt   werden,  um  die  Eindeutigkeit  desselben  zu
        erho"hen.  Nehmen wir beispielsweise an,  dass  die  Relation
        "lieferung"  nur  10 verschiedene Lieferanten, aber tausende
        Tupel  hat.   Die  Wahl  einer  iiiissssaaaammmm  -Struktur,   mit   den
        Schlu"sseln  llllnnnnuuuummmm und jjjjnnnnuuuummmm wird wahrscheinlich viel mehr ein-
        deutige Schlu"ssel ergeben.  Wie auch immer, die  Gro"sse  des
        "directories"  wird  zunehmen  und folglich dauert die Suche
        immer la"nger.  Wenn sie zur Erho"hung der  Eindeutigkeit  des
        Schlu"ssels  weitere  Doma"nen  zu  Schlu"ssel hinzufu"gen, ver-
        suchen sie mo"glichst die ku"rzesten auszuwa"hlen.

        _2._2._4._1_3.  SSSSyyyysssstttteeeemmmmkkkkaaaattttaaaallllooooggggeeee

        ING_DB  verwendet sieben Kataloge ( rrrreeeellllaaaattttiiiioooonnnn , rrrreeeeffffeeeerrrreeeennnncccceeeessss  ,
        aaaattttttttrrrriiiibbbbuuuutttteeee  ,  iiiinnnnddddeeeexxxxeeeessss  , ttttrrrreeeeeeee , pppprrrrooootttteeeecccctttt und iiiinnnnttttggggrrrriiiittttiiiieeeessss ), um
        Datenbanken zu verwalten und zu organisieren.  Der  rrrreeeellllaaaattttiiiioooonnnn
        -Katalog  hat  ein Tupel fu"r jede Relation in der Datenbank.
        Der aaaattttttttrrrriiiibbbbuuuutttteeee -Katalog hat ein Tupel fu"r jedes  Attribut  in
        jeder  Relation.   Der  iiiinnnnddddeeeexxxxeeeessss  -Katalog  hat ein Tupel fu"r
        jeden Sekunda"rindex.

        ING_DB  greift auf diese Kataloge in  einer  bestimmten  Art
        und  Weise zu.  Das Programm ssssyyyyssssmmmmoooodddd sollte verwendet werden,
        um diese Kataloge auf vordefinierten  Doma"nen  via  hhhhaaaasssshhhh  zu
        modifizieren.   Um  ssssyyyyssssmmmmoooodddd anzuwenden, gibt der Datenbankad-
        ministrator ein

        % sysmod Datenbankname

        ssssyyyyssssmmmmoooodddd sollte unmittelbar nach der Gru"ndung einer  Datenbank
        abgearbeitet  werden,  bzw.  nachdem  die Relationen erzeugt
        wurden. Die Datenbank  ist  nun  aufgebaut.   Es  ist  nicht
        ausreichend,  ssssyyyyssssmmmmoooodddd  einmal  zu starten und es dann zu ver-
        gessen.  Ein wiederholter Start von ssssyyyyssssmmmmoooodddd u"berarbeitet  die
        Systemkataloge.   Durch  die  Anwendung  werden  die meisten
        U"berlauf-Seiten  gelo"scht  und  die   Systemantwortzeit   in
        vielerlei Hinsicht verbessert.




        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 222 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        _2._2._5.  SSSSeeeekkkkuuuunnnnddddaaaa""""rrrriiiinnnnddddiiiizzzzeeeessss

        Die Verwendung einer iiiissssaaaammmm - oder hhhhaaaasssshhhh  -Struktur  gestattet,
        schnell  die  Tupel  einer  Relation zu finden und die Werte
        entsprechend der Schlu"seldoma"nen zu u"bergeben.  Manchmal ist
        das  aber  nicht  genug.   Nehmen wir beispielsweise an, wir
        ha"tten die "abgabe"-Relation

             abgabe(name, wert, ext)

        auf  nnnnaaaammmmeeee  via  hhhhaaaasssshhhh  geschlu"sselt.   Es  ergibt  sich   ein
        schneller  Zugriff  fu"r  Queries  mit einem exakten Wert fu"r
        nnnnaaaammmmeeee in der Qualifikation ( wwwwhhhheeeerrrreeee -Klausel).  Doch was  ist,
        falls  wir  den Queries einen exakten Wert fu"r eeeexxxxtttt u"bergeben
        wollen?

        aaaabbbbggggaaaabbbbeeee kann entweder fu"r nnnnaaaammmmeeee oder eeeexxxxtttt auf hhhhaaaasssshhhh gesetzt wer-
        den,  wir  ko"nnen wa"hlen, was anwendungsfreundlicher ist und
        aaaabbbbggggaaaabbbbeeee auf diese Doma"ne setzen.  Die  andere  Doma"ne  (sagen
        wir "ext") kann einen Sekunda"rindex (secondary index) haben.
        Ein Sekunda"rindex ist eine Relation, die die exakte Position
        der Tupel zu jedem eeeexxxxtttt in der Relation aaaabbbbggggaaaabbbbeeee entha"lt.

        Das Kommando zur Erzeugung eines Sekunda"rindexes ist:

             index on abgabe is abgext (ext)

        Die allgemeine Form lautet:

        index on relation_name is secondary_index_name (domains)

        Nun beauftragen wir ING_DB  ,  einen  Sekunda"rindex  in  der
        Relation  aaaabbbbggggaaaabbbbeeee zu erzeugen.  Die Doma"ne die indiziert wer-
        den soll, ist eeeexxxxtttt....  Indizes werden in drei Schritten  gebil-
        det:

        1.   aaaabbbbggggeeeexxxxtttt erzeugt ein hhhheeeeaaaapppp....

        2.   Fu"r jedes Tupel in aaaabbbbggggaaaabbbbeeee , wird ein Tupel mit dem Wert
             fu"r eeeexxxxtttt und der genauen Position des korrespondierenden
             Tupels in aaaabbbbggggaaaabbbbeeee in aaaabbbbggggeeeexxxxtttt eingefu"gt.

        3.   Standardma"ssig wird aaaabbbbggggeeeexxxxtttt zu iiiissssaaaammmm modifiziert.

        Wenn wir jetzt die Query

                range of a is abgabe
                retrieve(a.wert) where a.ext = 207

        starten,  wird  ING_DB    automatisch   zuerst   in   aaaabbbbggggeeeexxxxtttt
        nachsehen,  um  ext = 207 zu finden.  Wenn es dort ein Tupel
        findet, geht es direkt zum Tupel in  der  aaaabbbbggggaaaabbbbeeee  -Relation.
        Da  aaaabbbbggggeeeexxxxtttt  auf  iiiissssaaaammmm  fu"r eeeexxxxtttt gesetzt wurde, wird die Suche
        nach ext = 207 natu"rlich ebenfalls schnell erledigt sein.

        Wenn sie die Query

             retrieve(a.wert) where a.name = "frank"

        starten,  dann  wird  ING_DB   in  der  hhhhaaaasssshhhh  -Struktur  der



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 223 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        Relation  aaaabbbbggggaaaabbbbeeee versuchen fortzufahren, um die qualifizier-
        ten Tupel zu lokalisieren.

        Da Sekunda"rindizes eigensta"ndige Relationen sind, ko"nnen sie
        auch  (entweder)  hhhhaaaasssshhhh,,,, iiiissssaaaammmm,,,, cccchhhhaaaasssshhhh oder cccciiiissssaaaammmm sein.  Es ist
        nicht vernu"nftig, einen Sekunda"rindex auf hhhheeeeaaaapppp zu setzen.

        Die Beurteilung, welche Struktur geeignet ist,  ergibt  sich
        aus den Erkenntnissen, die zuvor diskutiert wurden:

        Werden die Doma"nen durch exakte Werte referenziert?
        Werden sie durch Wertebereiche referenziert?
        etc.

        In dem Fall, wo die eeeexxxxtttt -Doma"ne durch exakte Werte  referen-
        ziert  und die Relation beinahe gefu"llt ist, ko"nnen wir fol-
        gendes tun:

                modify abgext to hash on ext where fillfactor = 100
                and minpages = 1

        Sekunda"rindizes  stellen  in  ING_DB  einen  Weg  dar,  u"ber
        Doma"nen  auf  Tupel  zuzugreifen,  die keine Schlu"ssel sind.
        Eine Relation kann eine beliebige Anzahl von Sekunda"rindizes
        haben  und  ausserdem kann jeder Sekunda"rindex ein Index auf
        bis zu sechs Doma"nen einer Prima"rrelation sein.

        Wenn ein Tupel in einer Prima"rrelation  ersetzt  (replaced),
        gelo"scht  (deleted)  oder  angeha"ngt (appended) wird, mu"ssen
        alle Sekunda"rindizes auch aktualisiert werden,  die  Indizes
        kosten  was.  Sie erho"hen den Aufwand zur Aktualisierung der
        Prima"rrelation, aber sie ko"nnen den  Aufwand  zum  Auffinden
        von Tupel in der Prima"rrelation erheblich senken.

        Ob ein Sekunda"rindex die Geschwinigkeit der Recherche erho"ht
        oder  nicht,  ha"ngt  von  der  Eindeutigkeit  der  Werte der
        indizierten Doma"nen ab.   Die  Hauptfrage  bleibt,  ob  eine
        indirekte  Suche  u"ber  den Index effizienter als das Durch-
        suchen der gesamten Prima"rrelation ist.   Allgemein  ist  es
        effektiver, wenn die Anzahl der Tupel, die die Qualifikation
        ( where -Klausel) erfu"llen, kleiner ist, als die  Gesamtzahl
        der Seiten (Haupt- und U"berlauf-Seiten) der Prima"rrelation.

        Beispielsweise wollen wir ha"ufig alle Personen  wissen,  die
        weniger  als  fu"nf  Mark  verdienen,  dann  beachten sie den
        erzeugten Index

             index on abgabe is abgwert (wert)

        Standardma"ssig wird aaaabbbbggggwwwweeeerrrrtttt eine iiiissssaaaammmm  -Struktur  auf  wwwweeeerrrrtttt....
        Wenn ING_DB  die Query

             retrieve(a.name) where a.wert < 5.0

        ausfu"hrt, wird auf a.wert < 5.0 im Sekunda"rindex lokalisiert
        und fu"r jedes Tupel das gefunden wird, das korrespondierende
        Tupel in aaaabbbbggggaaaabbbbeeee geholt.  Die Tupel in aaaabbbbggggwwwweeeerrrrtttt sind nach wert
        sortiert,  die  Tupel in aaaabbbbggggaaaabbbbeeee jedoch nicht.  Damit wird im
        Allgemeinen jedes Tupel von aaaabbbbggggaaaabbbbeeee u"ber aaaabbbbggggwwwweeeerrrrtttt  adressiert,
        die  sich  aber  auf  verschiedenen Seiten befinden.  Solche



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 224 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        Recherchen u"ber einen Sekunda"rindex erfordern  mehr  Seiten-
        leseoperationen  (IO's),  als wenn die Prima"rrelation aaaabbbbggggaaaabbbbeeee
        sequentiell gelesen worden wa"re.  In solchen Fa"llen ist  die
        Erzeugung eines Sekunda"rindex' nicht zu empfehlen.

        _2._2._6.  WWWWiiiieeeeddddeeeerrrrhhhheeeerrrrsssstttteeeelllllllluuuunnnngggg ((((RRRReeeeccccoooovvvveeeerrrryyyy)))) uuuunnnndddd
             AAAAkkkkttttuuuuaaaalllliiiissssiiiieeeerrrruuuunnnngggg ((((UUUUppppddddaaaatttteeee))))


        _2._2._6._1.  EEEEiiiinnnnffffuuuu""""hhhhrrrruuuunnnngggg

        ING_DB  wurde sorgfa"ltig entworfen, um  die  Integrita"t  der
        Datenbank   bei   bestimmten   Arten  von  Systemfehlern  zu
        schu"tzen.  Um das  ING_DB   zu  ermo"glichen,  wird  bei  der
        Ausfu"hrung  von  Aenderungen  mit  dem  sogenannten ddddeeeeffffeeeerrrrrrrreeeedddd
        uuuuppppddddaaaatttteeee (verzo"gerte  Aktualisierung)  oder  bbbbaaaattttcccchhhhffffiiiilllleeee  uuuuppppddddaaaatttteeee
        (gepufferte Dateiaktualisierung) gearbeitet.  Weiterhin gibt
        es in ING_DB  zwei Programme rrrreeeessssttttoooorrrreeee (wiederherstellen)  und
        ppppuuuurrrrggggeeee  (reinigen), die verwendet werden ko"nnen, um nach auf-
        getretenen Systemfehlern die Datenbank zu testen und  wieder
        in  Ordnung  zu bringen.  Wir wollen zuerst diskutieren, wie
        "deferred updates" erzeugt und  ausgefu"hrt  werden  und  uns
        danach   mit   der   Verwendung   von   ppppuuuurrrrggggeeee   und  rrrreeeessssttttoooorrrreeee
        bescha"ftigen.

        _2._2._6._2.  DDDDeeeeffffeeeerrrrrrrreeeedddd UUUUppppddddaaaatttteeee uuuunnnndddd BBBBaaaattttcccchhhh UUUUppppddddaaaatttteeee


        _2._2._6._2._1.  UUUU""""bbbbeeeerrrrssssiiiicccchhhhtttt

        ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee  kann  man  mit  verzo"gerter  Aktualisierung
        u"bersetzen.

             Ein aaaappppppppeeeennnndddd -, rrrreeeeppppllllaaaacccceeee - oder ddddeeeelllleeeetttteeee -Kommando  wird  in
             vier Schritten ausgefu"hrt:

        1.   Ein leeres bbbbaaaattttcccchhhhffffiiiilllleeee (Pufferfile) wird erzeugt.

        2.   Das Kommando wird ausgefu"hrt  und  jede  Aenderung  der
             Relation wird in das bbbbaaaattttcccchhhhffffiiiilllleeee geschrieben.

        3.   Das bbbbaaaattttcccchhhhffffiiiilllleeee wird gelesen und die  Relation  und  ihre
             Sekunda"rindizes (falls vorhanden) werden aktualisiert.

        4.   Das bbbbaaaattttcccchhhhffffiiiilllleeee wird zersto"rt und ING_DB kehrt zum Nutzer
             zuru"ck.

        Das ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee verzo"gert die wirkliche A"nderung bis zum
        tatsa"chlichen Ende der Query.  Diese Vorgehensweise hat drei
        Vorteile:

        _2._2._6._2._2.  BBBBeeeesssseeeeiiiittttiiiigggguuuunnnngggg ddddeeeerrrr AAAAuuuusssswwwwiiiirrrrkkkkuuuunnnngggg vvvvoooonnnn SSSSyyyysssstttteeeemmmmffffeeeehhhhlllleeeerrrrnnnn

        Falls das System wa"hrend einer Aktualisierung zusammenbricht
        (  ccccrrrraaaasssshhhh  ), kann das ING_DB -Recovery-Programm entscheiden,
        entweder die A"nderung zu Ende auszufu"hren  oder  durch  bbbbaaaacccckkkk
        oooouuuutttt (Ablehnung) die A"nderung zuru"ckzusetzen und die Relation
        in dem Zustand zu belassen, in dem sie sich vorher befand.





        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 225 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        _2._2._6._3.  DDDDiiiieeee VVVVeeeerrrrhhhhiiiinnnnddddeeeerrrruuuunnnngggg eeeennnnddddlllloooosssseeeerrrr QQQQuuuueeeerrrriiiieeeessss

        Falls aaaabbbbggggaaaabbbbeeee ein hhhheeeeaaaapppp wa"re und die Query

                range of a is abgabe
                append to abgabe(a.all)

        wu"rde  ohne  ddddeeeeffffeeeerrrrrrrreeeedddd  uuuuppppddddaaaatttteeee  ausgefu"hrt,  dann  wird   die
        Ausfu"hrung  erst bei U"berlauf des Plattenspeichers bzw. wenn
        kein  freier  Platz  mehr  vorhanden  ist,   beendet!    Das
        geschieht  deshalb,  weil  ING_DB mit dem Lesen der Relation
        vorn anfa"ngt und jedes Tupel an das Ende angeha"ngt  (append)
        wird.   Es wu"rde bald beginnen, die Tupel zu lesen, die kurz
        vorher angeha"ngt worden sind und  unendlich  fortsetzen,  um
        das Ende zu erhaschen, das immer wieder entschwindet.

        Obwohl diese Query sicherlich nicht typisch ist, illustriert
        sie das Problem.  Es gibt bestimmte Klassen von Queries, bei
        denen Probleme durch aktualisierte Ablagen  beru"hrt  werden,
        die  nicht  pra"zise definiert sind.  Mit dem ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee
        kann garantiert werden, dass die Ergebnisse  konsistent  und
        logisch sind.

        _2._2._6._3._1.  BBBBeeeesssscccchhhhlllleeeeuuuunnnniiiigggguuuunnnngggg ddddeeeerrrr AAAA""""nnnnddddeeeerrrruuuunnnnggggsssszzzzeeeeiiiitttteeeennnn
              vvvvoooonnnn SSSSeeeekkkkuuuunnnnddddaaaa""""rrrriiiinnnnddddiiiizzzzeeeessss

        Sekunda"rindizes ko"nnen schneller aktualisiert  werden,  wenn
        alle  A"nderungen  auf einmal ausgefu"hrt werden, anstatt jede
        A"nderung einzeln.  Das schliesst auch den Schutz  ein,  dass
        der    Sekunda"rindex    die    Uebereinstimmung    mit   der
        Prima"rrelation beha"lt.

        _2._2._6._3._2.  AAAAbbbbsssscccchhhhaaaalllltttteeeennnn ddddeeeessss ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee

        Wenn sie von diesen Argumenten nicht u"berzeugt  wurden,  ge-
        stattet  ING_DB  auch,  das  "deferred update" abzuschalten!
        Tatsa"chlich gibt es sicher Fa"lle, wo es angebracht ist (aber
        natu"rlich nicht notwendig), die A"nderung direkt auszufu"hren,
        d.h. die Relation wird wa"hrend der Query gea"ndert.

        Um die direkte A"nderung anzuwenden, mu"ssen sie die Erlaubnis
        des  ING_DB  -  Systemadministrators haben.  Wenn sie das ----bbbb
        -Flag beim Start von ING_DB  verwenden,  wird  das  ddddeeeeffffeeeerrrrrrrreeeedddd
        uuuuppppddddaaaatttteeee ausgeschaltet.

        % quel -b meindb

        ING_DB  verwendet die direkte A"nderung  nur  fu"r  Relationen
        ohne  Sekunda"rindizes.   Die  Anwendung  des ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee
        wird fu"r Relationen mit Sekunda"rindex stillschweigend  immer
        benutzt.   Bei  Nutzung des ----bbbb -Flag mu"ssen sie auf die oben
        genannten Vorteile der verzichten.  In  den  meisten  Fa"llen
        sollte man das ----bbbb -Flag nnnniiiicccchhhhtttt aaaannnnwwwweeeennnnddddeeeennnn....

        Wenn sie ING_DB  so benutzen, dass sie  interaktiv  nur  ein
        Tupel  eingeben  oder  a"ndern,  ist  es  etwas gu"nstiger das
        ddddeeeeffffeeeerrrrrrrreeeedddd uuuuppppddddaaaatttteeee abzuschalten.  Wenn das System wa"hrend einer
        A"nderung  zusammenbricht,  ist  die eingebende Person in der
        Lage, festzustellen, ob das Tupel gea"ndert wurde oder nicht.




        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 226 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        _2._2._6._4.  RRRReeeessssttttoooorrrreeee

        ING_DB  ist so entworfen, dass nach  fast  allen  Typen  von
        Systemabstu"rzen  ein  Recovery  mo"glich  ist, falls das UNIX
        -File-System konsistent geblieben  ist.   Das  betrifft  die
        A"nderungskommandos,  das  uuuuppppddddaaaatttteeee  -,  ccccrrrreeeeaaaatttteeee  -,  ddddeeeessssttttrrrrooooyyyy -,
        mmmmooooddddiiiiffffyyyy - und auch das iiiinnnnddddeeeexxxx -Kommando.

        ING_DB   wurde  auf  ppppeeeerrrrffffeeeekkkktttteeee  SSSSiiiicccchhhheeeerrrrhhhheeeeiiiitttt  entworfen.   Wenn
        irgendeine   Nichtu"bereinstimmung  entdeckt  oder  irgendein
        Mangel von UNIX  zuru"ckgegeben wurde, generiert ING_DB  eine
        System-Error-Mitteilung (SYSERR) und bricht ab.

        Wenn UNIX  zusammenbricht, wa"hrend ING_DB arbeitet, oder ein
        ING_DB  -SYSERR auftritt, ist es generell sinnvoll, dass der
        Datenbankadministrator das Kommando

        % restore data_base_name

        gibt. Das Restore-Programm erfu"llt folgende Funktionen:

        1.   Es pru"ft die """"bbbbaaaattttcccchhhhffffiiiilllleeeessss""""....  Wenn es eins findet,  pru"ft
             es  jedes,  um festzustellen, ob es komplett ist.  Wenn
             der System-crash auftrat, wa"hrend das bbbbaaaattttcccchhhhffffiiiilllleeee  gerade
             gelesen  und  auf  die Datenbank ausgegeben wurde, dann
             holt rrrreeeessssttttoooorrrreeee die A"nderung nach.  Falls andererseits das
             bbbbaaaattttcccchhhhffffiiiilllleeee  noch  nicht vollsta"ndig war, wird es einfach
             zersto"rt, damit ist es so,  als  wa"re  die  Query  noch
             nicht ausgefu"hrt.

        2.   Test  auf  unvollsta"ndige  mmmmooooddddiiiiffffyyyy  -Kommandos.   Dieser
             Schritt  ist  entscheidend.   Er  garantiert,  dass sie
             entweder die Relation so vorfinden, wie vor der Modifi-
             kation,  oder  rrrreeeessssttttoooorrrreeee ist in der Lage das mmmmooooddddiiiiffffyyyy -Kom-
             mando zu vervollsta"ndigen.  mmmmooooddddiiiiffffyyyy arbeitet so, dass es
             eine  neue  Kopie  der  Relation  in der neuen Struktur
             erzeugt.  Wenn es dann fertig ist, ersetzt es die  alte
             Relation,  es  speichert die neuen Informationen in ein
             mmmmooooddddiiiiffffyyyy  bbbbaaaattttcccchhhhffffiiiilllleeee  (modifiziertes   Pufferfile).    Das
             befa"higt  rrrreeeessssttttoooorrrreeee  den Stand unfertiger Modifizierungen
             festzustellen.

        3.   Test auf  die  Uebereinstimmung  der  Systemrelationen.
             Dieser  Test  wird  verwendet, um ddddeeeessssttttrrrrooooyyyy -Kommandos zu
             vervollsta"ndigen, ccccrrrreeeeaaaatttteeee -Kommandos zuru"ckzusetzen  und
             iiiinnnnddddeeeexxxx     -Kommandos     zuru"ckzusetzen     oder     zu
             vervollsta"ndigen, die durch einen  System-crash  unter-
             brochen wurden.

        4.   Bereinigung tempora"rer Relationen und  Files.   rrrreeeessssttttoooorrrreeee
             fu"hrt  das ppppuuuurrrrggggeeee -Programm aus, um tempora"re Relationen
             und tempora"re Files, die vom System erzeugt wurden,  zu
             lo"schen.   ppppuuuurrrrggggeeee wird etwas spa"ter detaillierter disku-
             tiert.

        rrrreeeessssttttoooorrrreeee  kann  dem  Nutzer  nicht  sagen,   welche   Queries
        ausgefu"hrt wurden und welche nicht.  Es kann nur die Queries
        erkennen, die gerade liefen, als der crash erfolgte.   Falls
        Queries  auch  gerettet werden sollen, ist es am besten, sie
        in ein File auszugeben.   Gegebenenfalls  kann  der  Monitor



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 227 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


        jede  Query  oder  eine  Folge  von Queries ausgeben und der
        Nutzer spa"ter erkennen, welche Queries ausgefu"hrt wurden.

        rrrreeeessssttttoooorrrreeee hat mehrere Optionen zur Erweiterung seiner  Anwend-
        barkeit,  die durch Flags spezifiziert werden.  Die Optionen
        ermo"glichen:

        -a   fragt vor der Ausfu"hrung

        -f   verwendet fu"r ppppuuuurrrrggggeeee ; lo"scht tempora"re Files;

        -p   verwendet fu"r ppppuuuurrrrggggeeee ; lo"scht verfallene Relationen;

        no_database erneuert alle Datenbanken, fu"r die sie DBA sind;

        Von  diesen  Optionen  ist  ----aaaa  die  wichtigste.   Es   kann
        geschehen,  dass durch einen UNIX -crash eine Seite des Sys-
        temkataloges bescha"digt wird.  Das kann  dazu  fu"hren,  dass
        rrrreeeessssttttoooorrrreeee  eine Relation austra"gt (zersto"rt).  In Wirklichkeit
        wollen sie lieber zur Beseitigung des Problems die Systemka-
        taloge  flicken  (  ppppaaaattttcccchhhh  ),  um  korrekt weiterarbeiten zu
        ko"nnen.   Aber  kein  rrrreeeessssttttoooorrrreeee  -Programm   kann   fu"r   alle
        Mo"glichkeiten  eingerichtet  werden.   Es  ist  deshalb kein
        Ersatz (glu"cklicherweise !) fu"r den Menschen.

        Wenn ----aaaa spezifiziert ist, teilt  rrrreeeessssttttoooorrrreeee  mit,  was  es  tun
        wu"rde  und  fragt  dazu  nach  der  Erlaubnis.  Es liest von
        Standard-Input und akzeptiert yyyy als Anweisung zur Ausfu"hrung
        und die u"brigen Zeichen als Ablehnung.  Beispielsweise, wenn
        bei rrrreeeessssttttoooorrrreeee vor Ausfu"hrung gefragt werden soll, geben sie

             restore -a meindb

        Wenn sie auf alle Fragen nnnneeeeiiiinnnn antworten wollen, so geben sie

             restore -a meindb </dev/null

        Die Verwendung des ----aaaa -Flag fu"hrt dazu,  dass  rrrreeeessssttttoooorrrreeee  nach
        der   Genehmigung  zur  Ausfu"hrung  der  Bereinigung  fragt,
        beispielsweise, wenn es eine Doma"ne findet ohne dazugeho"rige
        Relation    oder,   wenn   es   einen   Sekunda"rindex   ohne
        Prima"rrelation findet, usw.

        Es gab kaum einen System-crash, den ING_DB nicht  bereinigen
        kann.  Damit ist nicht gemeint, dass sich solche Situationen
        nicht ergeben ko"nnen- sie sollten nicht sorglos werden.   Es
        muss daran erinnert werden, dass rrrreeeessssttttoooorrrreeee kein Ersatz fu"r das
        periodische Anlegen eines bbbbaaaacccckkkkiiiinnnngggg____uuuupppp (Sicherheitskopie)  ist
        und diese Funktion auch nicht erfu"llen soll.

        _2._2._6._5.  PPPPuuuurrrrggggeeee

        ppppuuuurrrrggggeeee kann verwendet werden, um  Ausku"nfte  u"ber  verfallene
        Relationen   zu   geben,   tempora"re   Systemrelationen   zu
        streichen, fremde Files zu lo"schen und verfallene Relationen
        auszutragen.   Um  ppppuuuurrrrggggeeee verwenden zu ko"nnen, mu"ssen sie der
        DBA der Datenbank sein.






        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 228 -                  DDDDaaaatttteeeennnnbbbbaaaannnnkkkk


             % purge meindb

        ppppuuuurrrrggggeeee hat mehrere Optionen,  die  durch  Flags  spezifiziert
        werden und folgendermassen lauten:

        -f   (Standard ausgeschaltet); Lo"schen aller fremden  Files;
             Jedes  File  wird angezeigt und dann gelo"scht.  Wenn ----ffff
             nicht spezifiziert ist, wird es nur angezeigt.

        -p   (Standard ausgeschaltet); Zersto"rung aller  verfallenen
             Relationen; Jede verfallene Relation wird angezeigt und
             wenn ----pppp spezifiziert ist, zersto"rt.

        ppppuuuurrrrggggeeee zersto"rt Relationen und Files immer dann, wenn sie  im
        ING_DB  -System tempora"rer Art sind.  Bei der Ausfu"hrung von
        Multi-Variablen- Queries und Queries mit  Aggregierungsfunk-
        tionen  erzeugt  ING_DB  gewo"hnlich tempora"re Relationen mit
        Zwischenergebnissen.  Diese Relationen  beginnen  immer  mit
        den  Zeichen  SSSSYYYYSSSS....   Auch  einige  andere  ING_DB -Kommandos
        erzeugen tempora"re Files, die mit SSSSYYYYSSSS  beginnen.   Bei  nor-
        malem  Ablauf  werden sie bei Beendigung gelo"scht.  Wenn ein
        System-crash  auftritt,  ko"nnte  das  unterbleiben.    ppppuuuurrrrggggeeee
        bereinigt  die tempora"ren Files des Systems, die Nutzerrela-
        tionen nur dann, wenn es explizit dazu aufgefordert wird.







































        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 229 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        _2._3.  ZZZZuuuuggggrrrriiiiffffffffssssmmmmeeeetttthhhhooooddddeeeennnn uuuunnnndddd ********
               DDDDaaaatttteeeennnnllllooookkkkaaaalllliiiissssiiiieeeerrrruuuunnnngggg












        _2._3._1.  EEEEiiiinnnnlllleeeeiiiittttuuuunnnngggg

        ING_DB    unterstu"tzt   mehrere   Zugriffsmethoden,    deren
        sinnvoller  Einsatz  dem  Projektanten  und dem Datenbankad-
        ministrator u"berlassen wird und  die  Zuordnung  von  Daten-
        banken  und  Relationen  in  eine  hierarchische UNIX -File-
        Struktur.

        Diese   Kapitel   beschreibt    die    Funktionsweise    der
        Zugriffsmethoden   und   gibt   damit   ,weiterfu"hrend   zum
        vorangegangenen, eine Anleitung zu ihrem effektiven problem-
        bezogenem  Einsatz.   Ausserdem  werden die Teile des ING_DB
        -Filesystems beschrieben, die den anwendungsbezogenen Aufbau
        mountbarer Filesysteme ermo"glichen.

        _2._3._2.  GGGGrrrruuuunnnnddddkkkkoooonnnnzzzzeeeepppptttteeee vvvvoooonnnn IIIINNNNGGGG____DDDDBBBB

        _2._3._2._1.  SSSSeeeeiiiitttteeeennnnkkkkoooonnnnzzzzeeeepppptttt uuuunnnndddd TTTTuuuuppppeeeellllddddaaaarrrrsssstttteeeelllllllluuuunnnngggg

        Alle Zugriffsmethoden legen den Datenbestand einer  Relation
        in  UNIX  -Files  ab.   Das File ist generierungsabha"ngig in
        Seiten von 512-Byte (UNIX   Version  7)  oder  1KByte  La"nge
        unterteilt.  Jedes  File fu"r eine Relation besteht aus einer
        ganzen Anzahl von Seiten, mindestens aber aus einer.

        Jede Seite entha"lt Tupel der  Relation  und  zwar  so,  dass
        jedes Tupel vollsta"ndig auf einer Seite untergebracht ist.

        Ein Tupel kann gewo"hnlich oder komprimiert gespeichert  wer-
        den:  Als  gewo"hnlich  gespeichertes  Tupel  wollen wir eine
        Speicherung verstehen, wo jedes  Attribut  des  Tupel  genau
        soviele  Bytes  belegt,  wie  beim  create  der Relation als
        Formatla"nge fu"r die entsprechenden Doma"nen definiert  wurde.
        Bei  den Doma"nen des Typs c (character) wird ha"ufig der Fall
        eintreten, dass deren Attribute  den  verfu"gbaren  Speicher-
        platz  nicht  voll  ausfu"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-Doma"nen  um  diese  rechten
        Leerstellen  verku"rzt  werden (das Ende des relevanten Teils
        des Attributes wird durch ein  zusa"tzliches  '\0'-Byte  mar-
        kiert  !  ).   Als  Spreizen  einer  Relation wollen wir die
        Transformation einer komprimierten in die  gewo"hnliche  Dar-
        stellung verstehen.

        Fu"r gewo"hnlich dargestellte  Relationen  kann  man  die  auf



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 230 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        einer Seite unterbringbaren Tupel berechnen als


                                            512 - 12
                Tupel pro Seite = ggZ (--------------------)
                                         Tupella"nge + 2

                (Tupella"nge in Byte,
                 ggZ: gro"sste ganze Zahl von )

        Man sieht, dass pro Seite generell 12 Bytes und pro Tupel  2
        Byte Verwaltungsplatz beno"tigt werden.

        Analog kann man sich ausrechnen, wieviel Restplatz auf jeder
        Seite frei bleibt, wenn die Tupella"nge so gewa"hlt wird, dass
        ein ganzes Vielfaches von ihr ( + 2  !  )  die  Seite  nicht
        ausfu"llt.   Maximal  darf  die Tupella"nge 498 Bytes betragen
        (pro Seite dadurch also ein Tupel !).  Die  Beziehungen  fu"r
        1024-Byte-Seiten  ko"nnen  mit  den gleichen absoluten Werten
        berechnet werden.

        Aus der Anzahl der Tupel und den auf einer Seite unterbring-
        baren,   kann   der,  fu"r  eine  Relation  insgesamt  no"tige
        Speicherplatz ausgerechnet werden.

        Fu"r komprimiert  dargestellte  Relationen  muss  man  eigene
        Abscha"tzungen verwenden.

        Wir bezeichnen eine Seite mit minimalem Restplatz  als  (100
        %-tig)  gefu"llt.   Der  Fu"llfaktor  einer  Seite  entspricht
        dem      durch  Tupel  belegten  Platz  im  Verha"ltnis   zum
        Gesamtplatz.

        _2._3._2._2.  SSSScccchhhhlllluuuu""""sssssssseeeellllbbbbeeeeggggrrrriiiiffffffff vvvvoooonnnn IIIINNNNGGGG____DDDDBBBB

        In der Relationentheorie bezeichnet man als Schlu"ssel  einer
        Relation  eine  derartige  Doma"ne (oder Gruppe von Doma"nen),
        deren   Attribute   allein   das   Tupel   charakterisieren.
        Beliebige  zwei Tupel einer Relation unterscheiden sich also
        mindestens in ihren Schlu"sseln.

        Wenn in der ING_DB -Dokumentation von Schlu"sseln  gesprochen
        wird,  ist  ein  anderer,  schwa"cherer Begriff gemeint.  Bei
        ING_DB  kann eine Doma"ne (oder  eine  Gruppe  von  in  ihrer
        Reihenfolge  gekennzeichneter  Doma"nen)  fu"r  die Sortierung
        oder Zugriffsunterstu"tzung herangezogen werden.   Fu"r  diese
        Doma"ne(n)  wird  dann vom Schlu"ssel der Relation gesprochen.
        ING_DB  unterstellt fu"r den Schlu"ssel  nicht  unbedingt  die
        o.g.  unifizierende  Eigenschaft,  dass sich zwei Tupel min-
        destens in ihren Schlu"sseln unterscheiden mu"ssen.

        Fu"r ING_DB  sind zwei Tupel genau dann gleich, wenn  sie  in
        allen paarigen Attributen u"bereinstimmen. An den Stellen, wo
        ING_DB  doppelte Tupel  ausschliesst,  wird  nicht  nur  auf
        Unterschiede  in den Schlu"sselattributen, sondern auf solche
        in allen paarigen Attributen getestet.







        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 231 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        _2._3._2._3.  SSSSeeeeiiiitttteeeennnnkkkkeeeetttttttteeeennnn

        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  Seitenkette  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
        U"berlaufseiten   bezeichnet.   Wir  bezeichnen  die  in  der
        Seitenkette enthaltenen Tupel  als  Tupelkette  der  Seiten-
        kette.

        Seitenkette      ___________
                         |         |
                         | Haupt   |
                         | Seite   |
                         |         |
                         ~~~~~~~~~~~
                             |         ....................
                         ___________     U"berlaufseiten
                         |         |
                         | Folge   |
                         | Seite   |
                         |         |
                         ~~~~~~~~~~~
                             |
                             :
                             :
                             :


        Gemeinsam bei allen Zugriffsmethoden ist:

           - Die Suche eines Tupels  in  einer  Seitenkette  erfolgt
             sequentiell.

             Sieht man von den hier nicht darzustellenden Dekomposi-
             tionsverfahren  bei retrieve-Anweisungen mit Aggregaten
             oder u"ber mehrere Relationen ab,  erfolgt  die  Anzeige
             aufgefundener  Tupel unmittelbar in der Reihenfolge der
             Tupelkette.


             Das Anfu"gen (append) eines Tupel in  einer  Seitenkette
             erfolgt  hinten  an die Tupel der laufenden Seite; wenn
             dafu"r kein Platz mehr ist, wird die Seitenkette um eine
             neue Seite verla"ngert.

             Dadurch geht die anfangs bestehende  Reihenfolgeordnung
             der  Tupel  in  einer Seite und auch in der Seitenkette
             verloren.


             Beim Streichen (delete) eines Tupel wird der Platz  des
             Tupel   freigegeben  und  die  Seite  komprimiert;  die
             Seitenkette wird nicht komprimiert.

        Unterschiede zwischen den Zugriffsmethoden bestehen darin:




        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 232 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


           - bei der heap-Technik wird die gesamte Relation in einer
             einzigen   Seitenkette   abgelegt,  bei  den  Direktzu-
             griffsmethoden hash und  isam besteht die Relation  aus
             mehreren  Seitenketten.  Die Unterschiede bei letzteren
             Techniken  bestehen  in  der  Art  der  Zuordnung   von
             Schlu"sselwerten  zu  den verschiedenen Seitenketten der
             Relation.


             Bei der  heap-Technik  werden  doppelte  Tupel  in  der
             Seitenkette zugelassen, bei den Direktzugriffstechniken
             nicht.

             Daraus ergeben sich  Unterschiede  beim  Anfu"gen  neuer
             Tupel:
             Bei heap erfolgt die Einspeicherung am Ende der  Tupel-
             kette,  bei  hash und isam muss die gesamte Seitenkette
             durchsucht werden, um doppelte  Tupel  auszuschliessen,
             das Anfu"gen erfolgt auf dem ersten ausreichenden freien
             Platz der Seitenkette.  Bei heap wird dadurch der durch
             delete entstandene freie Platz nicht wieder ausgenutzt.

             Daraus ergeben sich  auch  Unterschiede  beim  Ersetzen
             (replace)   in   komprimierten  Relationen  in  solchen
             Fa"llen, wo das Ersetzen  ggf.  nicht  inplace  erfolgen
             kann.    Dann   wird   replace  in  delete  und  append
             aufgelo"st.  Beachten sie, dass  jedes  gefundene  Tupel
             ersetzt  wird,  replace also die Anzahl der Tupel einer
             Relation nicht a"ndert.

        _2._3._3.  ZZZZuuuuggggrrrriiiiffffffffsssstttteeeecccchhhhnnnniiiikkkkeeeennnn vvvvoooonnnn IIIINNNNGGGG____DDDDBBBB

        _2._3._3._1.  HHHHeeeeaaaapppp

        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) gefu"llt.  Die Tupel sind unsortiert.  Die Rela-
        tion entha"lt ggf. doppelte Tupel.

        append fu"gt Tupel hinten  an  (ggf.  werden  weitere  Seiten
        angekettet !).  delete gibt Speicherplatz auf der jeweiligen
        Seite frei; um die zu lo"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 qualifizierenden  Tupel  in  der
        gefundenen, unsortierten Reihenfolge.

        heap und cheap  sind  geeignete  Zugriffstechniken,  um  aus
        einer  leeren  Relation  durch sukzessives Anfu"gen oder copy
        from eine Relation aufzubauen.  Eine  effektive  Arbeit  mit
        dieser  Zugriffstechnik  ist aber nur bei kleinen Relationen
        denkbar.

        _2._3._3._2.  HHHHeeeeaaaappppssssoooorrrrtttt

        heapsort ist keine  Speichertechnik  sondern  Zustand  einer
        Relation   nach   Ausfu"hrung  eines  entsprechenden  modify-
        Statements; die Relation ist in der Folge ein heap.



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 233 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        Bei der Ausfu"hrung eines modify to heapsort wird  die  Rela-
        tion  nach  den angesprochenen Doma"nen sortiert, werden dop-
        pelte Tupel  gestrichen  und  wird  die  Relation  als  heap
        abgelegt.

        Zur Durchfu"hrung der Sortierung wird die Relation gespreizt,
        falls   sie   komprimiert   gespeichert   war.    Es  werden
        Sortierarbeitspla"tze als Files im SYS-directory angelegt.

        _2._3._3._3.  HHHHaaaasssshhhh

        Fu"r  eine  als  hash  dargestellte  Relation   besteht   ein
        Direktzugriff   auf  ein  Tupel,  wenn  der  Wert  seines(r)
        Schlu"sselattribute(s) vollsta"ndig  angegeben  wird.   Dieser
        Zugriff wird wie folgt vollzogen:

        Durch eine hash-Funktion wird aus dem Schlu"sselattribut  die
        Adresse  (der  hash-Code)  einer  Hauptseite berechnet.  Die
        hash Funktion berechnet also nach einem besonderen Verfahren
        aus  einem irgendwie strukturiertem Schlu"ssel eine Zahl, die
        in einem Intervall

                           0 <= Hauptseite <= N-1

        liegt.  N bezeichnen  wir  als  Spreizungsbreite  der  hash-
        Funktion.   Diese  dadurch jeweils errechnete Hauptseite ist
        Anfangsseite einer Seitenkette, die alle die Tupel der Rela-
        tion  entha"lt, deren Schlu"ssel den gleichen hash-Code haben.
        In  diesen  Seitenketten  werden   keine   doppelten   Tupel
        zugelassen.  Die Relation kann insgesamt als unsortiert auf-
        gefasst werden, da die  hash-Funktion  keinen  "natu"rlichen"
        Wert aus dem Schlu"ssel bildet.

                                                0
                                                1
                       hash(Schlu"sselwert) =    :
                                                :
                                               N-1


                     0         1      .........    N-1
                ________  ________              ________
                |      |  |      |              |      |
                |Seiten|  |Seiten|    ......... |Seiten|
                |kette |  |kette |              |kette |
                |      |  |      |              |      |
                ~~~~~~~~  ~~~~~~~~              ~~~~~~~~



        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 Ausfu"hrung des modify erfolgt durch
        sukzessives insert in eine neue Relation.  Die alte Relation
        wird  aus Sicherheitsgru"nden erst freigegeben, wenn die neue
        erzeugt ist.  Beim create einer leeren Relation kann man mit
        modify eine gewu"nschte Spreizungsbreite einstellen.

        hash und chash  sind  geeignete  Zugriffstechniken,  um  aus



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 234 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        einer  leeren  Relation durch sukzessives Anfu"gen oder durch
        copy from eine Relation aufzubauen.

        ING_DB  unterstu"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  fu"r jede Seitenkette mindestens eine Hauptseite reser-
        viert.

        Die  Suche  in  einer  hash-Relation  fu"r  einen   einzelnen
        Schlu"sselwert   fu"hrt   u"ber   dessen   hash-Code   auf  die
        Hauptseite, wo sequentiell weiter gesucht wird.   Die  Suche
        nach  einem  Schlu"sselintervall  zwingt  zum Durchsuchen der
        gesamten Relation.  Deshalb ist die hash-Technik ungeeignet,
        wenn  ha"ufig Suchpfade u"ber Schlu"sselintervalle benutzt wer-
        den mu"ssen.

        Das A"ndern in einer  Relation  erfolgt  einschliesslich  der
        Suche  und  dem Ausschluss der Anlage doppelter Tupel.  Beim
        Erga"nzen neuer Tupel wird die  betroffene  Seitenkette  ggf.
        durch  U"berlaufseiten  erga"nzt, die an die vorherigen Seiten
        der Seitenkette angekettet werden.

        _2._3._3._4.  IIIIssssaaaammmm

        Fu"r  eine  als  isam  dargestellte  Relation   besteht   ein
        Direktzugriff   auf  ein  Tupel,  wenn  der  Wert  seines(r)
        Schlu"sselattribute(s) angegeben  wird  und  besteht  daru"ber
        hinaus   die   Mo"glichkeit,   Schlu"sselintervalle  in  einer
        anna"hernden Sortierung abzugreifen.

        Fu"r  isam  ist  ein  aus  mehreren  Komponenten  bestehender
        Schlu"ssel  soweit  definiert  und  ggf.   fu"r einen direkten
        Zugriff nutzbar,  wie  seine  ersten  Komponenten  lu"ckenlos
        definiert sind.

        Der Zugriff wird wie folgt organisiert:

        Durch einen Adress-B*-Baum wird  aus  dem  Schlu"sselattribut
        die Adresse einer Hauptseite berechnet.

        Ein B*-Adressbaum entha"lt in jeder Baumebene eine Folge  von
        Seiten.  Eine derartige Folge von Seiten entha"lt aufsteigend
        geordnete Schlu"ssel von Seiten der darunter liegenden  Baum-
        ebene,  also  der  Nachfolgeebene.   Aus  der  Position  des
        Schlu"ssels kann die  betreffende  Seite  der  Nachfolgeebene
        bestimmt  werden.   Diese  entha"lt  ab dem sie definierenden
        Anfangsschlu"ssel alle, die kleiner als der  Anfangsschlu"ssel
        ihrer,  in  gleicher Baumebene liegenden, Nachbarseite sind.
        Der B*-Baum wird nach unten durch Hauptseiten von Seitenket-
        ten  abgeschlossen, die zu den Schlu"sseln auch alle weiteren
        Attribute als vollsta"ndige  Tupel  enthalten.   Der  B*-Baum
        erha"lt  nach  oben  soviele Ebenen, bis die Wurzelebene ganz
        auf einer Seite darstellbar ist.

        Nehmen wir als Beispiel Schlu"ssel von ganzen Zahlen  an  und
        nehmen  wir  weiter an, dass auf einer Seite der Seitenkette
        der Relation 5 Tupel unterbringbar wa"ren,  auf  einer  Seite



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 235 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        des B*-Baumes aber 25 Adressen.  Dann wa"re folgender B*-Baum
        mit zwei Baumebenen denkbar:


                             ______________________________
                             |  5   130                   |
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              ________________________ ________________________
              |   5    10  ....   125| |130   135   ....   255|
              ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~

        _____ _____ _____        _____ _____ _____        _____
        |   | |   | |   |        |   | |   | |   |        |   |
        | 0 | | 5 | | 10|        |125| |130| |135|        |255|
        | : | | : | | : | .....  | : | | : | | : | .....  | : |
        | : | | : | | : |        | : | | : | | : |        | : |
        | 4 | | 9 | | 14|        |129| |134| |139|        | : |
        |   | |   | |   |        |   | |   | |   |        |   |
        ~~~~~ ~~~~~ ~~~~~        ~~~~~ ~~~~~ ~~~~~        ~~~~~


        Die Genauigkeit des B*-Baumes wu"rde gewa"hrleisten,  dass  im
        Schlu"sselintervall  0  ...  254  maximal 5 Tupel sequentiell
        gesucht werden  mu"ssten,  dass  in  diesem  Intervall  keine
        U"berlaufseiten  auftreten  und dass bei der Ausgabe Sortier-
        abweichungen nur in 5-er Schritten auftreten ko"nnten:
        z.B.

                            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

        Allerdings wu"rden alle Tupel mit Schlu"sselwerten ab  255  in
        die letzte Seitenkette eingeordnet werden.

        Beenden wir hiermit das Beispiel.

        Der B*-Baum ist Bestandteil der Relation.

             (seine La"nge ist berechenbar:

             -  Tupella"nge der Adresse:
                gespreizter Schlu"sselcode

                jede Baumebene ganz in Seiten)

        Die  durch  den   B*-Baum   ermittelten   Hauptseiten   sind
        Anfangsseiten  von  Seitenketten,  die unsortiert alle Tupel
        enthalten und deren Schlu"ssel den gleichen Baumpfad  nehmen.
        In   diesen   Seitenketten   werden  keine  doppelten  Tupel
        zugelassen.  Die B*-Baum-Struktur gewa"hrleistet fu"r  gewisse
        Schlu"sselintervalle eine Sortierung untereinander.

        Der B*-Baum wird bei der Erzeugung der Relation angelegt und
        bleibt  u"ber  deren gesamte Lebensdauer fest.  Es ist unsin-
        nig, eine leere Relation als isam zu  gru"nden,  der  B*-Baum
        wa"re  entartet, man wu"rde eine einzige Seitenkette erzeugen,
        bei dem bei jedem Einfu"gen eines neuen Tupel eine  Duplikat-
        kontrolle  u"ber  alle  bereits  vorhandenen  Tupel  erfolgen



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 236 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF


        wu"rde.

        Bei der Erzeugung der isam Relation durch  modify  kann  man
        die  Genauigkeit  des  B*-Baumes  durch  den  Fu"llfaktor der
        Hauptseiten bestimmen.  Die alte Relation wird  zuna"chst  in
        eine  Speicherungsform analog heapsort u"berfu"hrt, diese wird
        danach, entsprechend dem Fu"llfaktor, gespreizt und u"ber  den
        so entstandenen Hauptseiten wird der B*-Baum aufgebaut.

        Die Suche in einer isam Relation kann  fu"r  die  Angabe  von
        einzelnen Schlu"sselwerten, als auch fu"r Intervalle von ihnen
        unterstu"tzt werden.  Das Anfu"gen  erfolgt  zuna"chst  in  den
        Hauptseiten  -  soweit der Fu"llfaktor des erzeugenden modify
        vorausschauend genu"genden Restplatz definiert - danach  wer-
        den der jeweiligen Seitenkette U"berlaufseiten angefu"gt.  Das
        A"ndern in der Relation erfolgt einschliesslich der Suche und
        dem Ausschluss der Anlage doppelter Tupel.

        _2._3._4.  DDDDiiiieeee GGGGeeeessssttttaaaallllttttuuuunnnngggg ddddeeeessss DDDDaaaatttteeeennnnbbbbaaaannnnkkkkffffiiiilllleeeessssyyyysssstttteeeemmmmssss
        ffffuuuu""""rrrr IIIINNNNGGGG____DDDDBBBB

        _2._3._4._1.  EEEEiiiinnnnoooorrrrddddnnnnuuuunnnngggg eeeeiiiinnnneeeerrrr DDDDaaaatttteeeennnnbbbbaaaannnnkkkk

        ING_DB  wird installationsabha"ngig unter einem  Anfangspfad-
        namen

                                  Pathname

        installiert. Zum Beispiel ist

                           Pathname = /mnt/ing_db

        eingerichtet.

        Unter diesem Pathname liegen eine Reihe  hier  nicht  behan-
        delter Files und directories.  Die Datenbanken sind unter

                             Pathname/data/base

        eingerichtet, jede  Datenbank  erha"lt  ein  directory  ihres
        Namens:

                         Pathname/data/base/dbname

        In jedem directory dbname liegen


           - dbname/admin
             das s.g. admin-File mit  allgemeinen  Datenbankinforma-
             tionen,


             die Systemkataloge  (die  Relationen  relation,  refer-
             ences,  attributes,  integrity,  protect, indexes), die
             Relationen (Relationen schlechthin, Indizes)

        Durch diese Struktur sind insbesondere






        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 237 -                    ZZZZUUUUGGGGRRRRIIIIFFFFFFFF



                              base       oder
                              dbname     oder
                              SYS

        mountbar.

        Bei Erzeugung  einer  Datenbank  mittels  creatdb  wird  das
        directory  dbname  angelegt  und  werden  die Systemkataloge
        eingerichtet.

        _2._3._4._2.  BBBBeeeewwwweeeerrrrttttuuuunnnngggg ddddeeeessss RRRReeeellllaaaattttiiiioooonnnneeeennnnnnnnaaaammmmeeeennnnssss

        ING_DB  speichert alle Daten einer Relation  in  einem  UNIX
        -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

           - ggf.  durch  Leerzeichen   (<blank>)   auf   12   Bytes
             verla"ngert;
             dabei wird das erste in 2. bis 11.  Position  gefundene
             "_" (<underscore>) durch "/" (<slash>) ersetzt;

             den 12 Bytes werden 2 Bytes als  Code  des  arbeitenden
             Nutzers  (s.  auch  -u-Flag bei quel(unix) im Referenz-
             Manual) angefu"gt.

        Dadurch wird es mo"glich, dass

        -    verschiedene Nutzer private Relationen gleichen  Namens
             in der gleichen Datenbank anlegen ko"nnen;

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



























        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 238 -                    MMMMoooonnnniiiittttoooorrrr


        _2._4.  MMMMoooonnnniiiittttoooorrrr ********












        _2._4._1.  EEEEiiiinnnnffffuuuu""""hhhhrrrruuuunnnngggg

        Der Monitor realisiert die interaktive Arbeit  mit  dem  DBS
        ING_DB  .   Die Monitor-Kommandos erlauben in Zusammenarbeit
        mit einem Editor und  dem  ING_DB  -Makro-Prozessor  gewisse
        Manipulationen  an  einem  Text  von  QUEL-Statements, bevor
        diese aus dem  Monitor-Puffer  an  den  ING_DB  -Parser  zur
        Analyse und zur Veranlassung ihrer Ausfu"hrung u"bergeben wer-
        den.   Die  Monitor-Kommandos  erlauben  die  Steuerung  der
        Arbeit  mit  ING_DB   aus  vorgefertigten Kommandofiles, die
        Monitor-Kommandos,  Makro-Anweisungen  und   QUEL-Statements
        enthalten ko"nnen.
        Der Monitor ist der front_end_process des DBS ING_DB  .   Er
        liest  einen  Eingabetext  - prima"r von standard_input - und
        analysiert diesen auf Monitor-Kommandos.  Der Monitor  fu"hrt
        in  seinem  Eingabetext  gefundene  Monitor-Kommandos sofort
        aus, anderer Text wird in den Monitor-Puffer gestellt.
        Beispiele fu"r eine komplexe Anwendung des Monitors sind erst
        in  Verbindung mit Makros interessant und finden sich in der
        "Beschreibung  des   Makro-Prozessors"   und   dem   Kapitel
        "Beispiele fu"r Monitor und Makro-Prozessor".

        _2._4._2.  MMMMooooddddiiiiffffiiiikkkkaaaattttiiiioooonnnneeeennnn dddduuuurrrrcccchhhh OOOOppppttttiiiioooonnnneeeennnn

        Der Monitor wird durch folgende Optionen gesteuert:

                -d Unterdru"ckung der Ausgabe des dayfile
                   (s. Startvorgang und Arbeitszyklus)
                -s Unterdru"ckung der Ausgabe von Prompt-Meldungen
                   (s. Startvorgang und Arbeitszyklus)
                -a Unterdru"ckung des automatischen Lo"schens des
                   Monitor-Puffers
                   (Ausschalten des autoclear_modus)
                   (s.Arbeit mit dem Monitor-Puffer)


        _2._4._3.  SSSSttttaaaarrrrttttvvvvoooorrrrggggaaaannnngggg uuuunnnndddd AAAArrrrbbbbeeeeiiiittttsssszzzzyyyykkkklllluuuussss

        Beim Start von ING_DB  wird neben dem DBS  der  Monitor  ge-
        startet.

        Der Monitor definiert den Makro

                                "{pathname}"

        mit dem Pfadnamen des ING_DB -File-Systems.   (Folgend  wird
        in diesem Kapitel ein File_name unter diesem Pfadnamen mit



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 239 -                    MMMMoooonnnniiiittttoooorrrr



                             ing_db/<file_name>

        symbolisiert.)

        Der Monitor definiert weiter den Makro

                                "{usercode}"

        mit dem 2-Byte-\*(yy-Usercode (s. usersfile des  arbeitenden
        Nutzers.

        Der Monitor meldet sich durch Ausgabe der

                ING_DB
                -login-Meldung

                "ing_db version <Versions_nummer> login
                 <aktuelle_Zeitangabe>"


        Diese  Ausgabe  wird  durch  die  Option  "-s"  unterdru"ckt.
        Anschliessend wird das

                           ing_db/sys/etc/dayfile

        angelistet, was durch die  Option  "-d"  unterdru"ckt  werden
        kann.   Mit  der  Ausgabe  des  dayfile  sollen  den  ING_DB
        -Nutzern aktuelle Informationen vermittelt  werden.   Da  es
        allen  Nutzern  angeboten  wird,  ist  es nicht zur Aufnahme
        nutzerspezifischer Informationen geeignet.

        Durch den Monitor werden danach  nacheinander  die  Monitor-
        Kommandos

                      \include ing_db/sys/etc/startup
                      \include <initfile>

        automatisch ausgefu"hrt, was zur Abarbeitung von Kommandofol-
        gen  fu"hren kann, falls generell im startupfile fu"r ING_DB ,
        oder spezifisch fu"r den Nutzer (Angabe im 7.Feld der Nutzer-
        zeile des ing_db/sys/etc/users) solche Files angelegt wurden
        (s. auch \include-Kommando).

        Danach geht der Monitor in den  Eingabe-Status  und  beginnt
        seinen Arbeitszyklus.

        Zu Beginn des Eingabe-Status meldet sich der Monitor mit den
        Prompt-Meldungen

                          "<bell_signal> ING_db>"

        wenn der Monitor-Puffer leer ist, oder mit

                          "<bell_signal> ING_db:"

        wenn der Monitor-Puffer  nicht  leer  ist  und  zeigt  seine
        Eingabebereitschaft durch das

                             Prompt-Symbol "* "



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 240 -                    MMMMoooonnnniiiittttoooorrrr


        zu jedem Zeilenanfang.  Die Ausgabe der Prompt-Meldungen und
        auch   des   Prompt-Symbols   wird  durch  die  Option  "-s"
        unterdru"ckt.   Davon  unberu"hrt  bleibt  die  Ausgabe  aller
        anderen folgend aufgeza"hlten Meldungen zur Fehleranzeige.

        Der Monitor liest den  Eingabetext  in  den  Monitor-Puffer,
        filtert  die Monitor-Kommandos heraus und fu"hrt diese sofort
        aus.

        Das spezielle Monitor-Kommando  \go  (s.dort)  u"bergibt  den
        Monitor-Puffer   an  den  Parser,  der  die  QUEL-Statements
        analysiert und ausfu"hren la"sst.  Mit U"bernahme  dieses  Kom-
        mendos meldet der Monitor

                              "ING_db . . . "

        (diese Meldung unterbleibt, wenn  die  Option  "-s"  gesetzt
        ist) und versetzt sich in einen Warte-Status.

        Der Monitor wird nach Abschluss der Arbeiten des Parsers und
        den,   diesen  nachgelagerten  weiteren  ING_DB  -Prozessen,
        wieder in den Eingabe-Status  versetzt  und  beginnt  erneut
        seinen Arbeitszyklus.

        Nach   Start   von   ING_DB   arbeitet   der   Monitor   von
        standard_input   (i.d.R.  also  vom  Terminal).   Durch  ein
        \include-Kommando  (s.  dort)  arbeitet  er   danach   file-
        gesteuert,  sein  included_file  ist der Eingabetextspender.
        Da man die Files hintereinander liegender \include-Kommandos
        als  Programm-Ebenen betrachten kann, sagen wir, der Monitor
        arbeitet nach Start in der  Basis-Terminal-Ebene  und  durch
        \include-Kommandos in darunter liegenden Programm-Ebenen.

        Die Ausgaben des Monitor erfolgen immer auf  standard_output
        (i.d.R.  also ebenfalls auf dem Terminal).  Die Eingaben der
        Funktions-Makros   {read...},   {readdefine...}    (s.Makro-
        Prozessor)    erfolgen    in   allen   Programm-Ebenen   von
        standard_input.

        Der Arbeitszyklus des Monitor  und  damit  auch  die  ING_DB
        -Sitzung  wird  mit Ausfu"hrung eines \quit-Monitor-Kommandos
        (s.dort) oder  nach  Einlesen  eines  <eof>  in  der  Basis-
        Terminal-Ebene (s. \include-Kommando) beendet.

        Bei  der   Ausfu"hrung   von   Monitor-Kommandos   wird   der
        Makroprozessor  (s.  dessen  Kapitel) benutzt.  Folgend wird
        der Output-Text, den der Makroprozessor aus einem Input-Text
        erzeugt, als

                         < MACRO ( <Input_Text> ) >

        symbolisiert.

        _2._4._4.  AAAArrrrbbbbeeeeiiiitttt mmmmiiiitttt ddddeeeemmmm MMMMoooonnnniiiittttoooorrrr----PPPPuuuuffffffffeeeerrrr

        Bei der Eingabe vom Terminal wird der Eingabetext vom  Moni-
        tor  erst  als  vollsta"ndige Zeile (also erst nach Eintasten
        des <nl> ) u"bernommen.  Vorher sind Korrekturen  mit  <kill>
        oder  <erase>  mo"glich.   Nach  U"bernahme  der  Zeile ko"nnen
        Korrekturen im Monitor-Puffer nur noch  durch  die  Monitor-



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 241 -                    MMMMoooonnnniiiittttoooorrrr


        Kommandos \reset oder \editor ausgefu"hrt werden.

        Der Monitor lehnt die Eingabe aller Zeichen, deren  Codewert
        kleiner  als oktal 040 ist, ausser <tab>, <nl> und <escape>,
        ab.  Genauer gesagt, er wandelt sie in ein  <blank>  um  und
        signalisiert das durch die Meldung

                    "Zeichen 0** konvertiert in blanks"

        Die im Monitor-Puffer  formulierten  QUEL-Statements  werden
        mit  einem  \go-Kommando  zur Ausfu"hrung angewiesen.  Danach
        kann der Monitor-Puffer in der Regel gelo"scht  werden.   Das
        passiert  auch  im  sogenannten autoclear_mode.  Das Lo"schen
        erfolgt nicht, wenn man sich nach Ru"ckkehr in  den  Eingabe-
        Status  des  Monitor sofort noch einmal fu"r den alten Inhalt
        des Monitor-Puffers interessiert.

        Der autoclear_mode wird durch die Option "-a"  abgeschaltet.
        Mit  dieser  Option  muss  man in allen Fa"llen selbsta"ndig -
        durch ein \reset-Kommando - den Monitor-Puffer lo"schen.

        Genauer gesagt, la"uft folgendes ab:
        Nach einem \go-Kommando ist der Monitor-Puffer zuna"chst noch
        unvera"ndert.   Er  wird  jetzt aber zur Lo"schung vorgemerkt.
        Diese Vormerkung kann durch die Option "-a" unterdru"ckt wer-
        den.  Die Ausfu"hrung eines vorgemerkten Lo"schens ha"ngt davon
        ab, welches Monitor-Kommando folgt:
        Die Kommandos \append, \print, \list, \edit machen die  Vor-
        merkung  ru"ckga"ngig;  das  Kommando \reset fu"hrt ohnehin ein
        Lo"schen aus, alle anderen Kommandos beru"cksichtigen die Vor-
        merkung  nicht,  \eval setzt sie selbst.  Die Ausfu"hrung der
        vorgemerkten Lo"schung erfolgt unmittelbar vor und anla"sslich
        der Eintragung des ersten Nicht-Kommando-Zeichens des Einga-
        betextes in den Monitor-Puffer.

        Durch dieses automatische Lo"schen des Monitor-Puffers sollen
        die normalen Arbeitszyklen

                <QUEL-Statement>
                \go
                <neues_QUEL-Statement>
                \go

        oder z.B.

                <QUEL-Statement>
                \go
                \append | \editor
                <Qualifizierung des alten QUEL-Statements>
                \go

        unterstu"tzt werden.

        _2._4._5.  SSSSyyyynnnncccchhhhrrrroooonnnneeee BBBBeeeeeeeennnnddddiiiigggguuuunnnngggg uuuunnnndddd
               aaaassssyyyynnnncccchhhhrrrroooonnnneeee UUUUnnnntttteeeerrrrbbbbrrrreeeecccchhhhuuuunnnngggg

        Durch Abgabe eines Interruptsignals  wird  der  Warte-Status
        des Monitor beendet.  Das bedeutet, dass die vom Parser ini-
        tiierten ING_DB -Prozesse asynchron zum Abbrechen veranlasst
        werden  (Achtung:  Bei  QUEL-Statements,  die die Datenbasis



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 242 -                    MMMMoooonnnniiiittttoooorrrr


        a"ndern, besteht darin eine  gewisse  Gefahr!).   Die  Abgabe
        eines   Interruptsignals,   wa"hrend   sich  der  Monitor  im
        Eingabe-Status befindet, ist wirkungslos.

        Die  Abgabe  eines  Interruptsignals   wa"hrend   der   file-
        gesteuerten  Arbeit  des  Monitor  fu"hrt zur Ru"ckkehr in die
        Basis-Terminal-Ebene.

        Ein <EOF> in einer, unter der Basis-Terminal-Ebene liegenden
        Programmebene  (s.  \include-Kommando) fu"hrt zur Ru"ckkehr in
        die daru"ber liegende Programm-Ebene und die der letzten  zur
        Beendigung des Monitors ( wie Monitor-quit-Kommandos ).


        _2._4._6.  SSSSttttrrrruuuukkkkttttuuuurrrr ddddeeeerrrr MMMMoooonnnniiiittttoooorrrr----KKKKoooommmmmmmmaaaannnnddddoooossss

        Ein Monitor-Kommando ist eine Zeichenfolge der Form

                "\" {<blank>|<tab>} <m_c_name> [<parm>]

        mit

                <parm> =
                     {<blank>|<tab>}<Zeichenfolge> <nl> ;


        und
                <m_c_name> =



                         "H"    | "help"    |
                         "a"    | "append"  |
                         "b"    | "branch"  |
                         "cd"   | "chdir"   |
                         "e"    | "ed"      | "edit"  | "editor" |
                         "g"    | "go"      |
                         "h"    | "help"    |
                         "i"    | "include" | "read"  |
                         "k"    | "mark"    |
                         "l"    | "list"    |
                         "p"    | "print"   |
                         "q"    | "quit"    |
                         "r"    | "reset"   |
                         "s"    | "sh"      | "shell" |
                         "d"    | "time" | "date"  |
                         "v"    | "eval"    |
                         "w"    | "write"   |
                         "m"    | "monitor";


        Das sind die Monitor-Kommando-Namen mit ihren Alias-Namen.

        Die <parm> sind abha"ngig vom jeweiligen Kommandotyp und wer-
        den  dort  beschrieben.   Es gibt grundsa"tzlich drei Gruppen
        von Kommandos: solche, die
             keinen <parm> haben,
             wahlweise einen <parm> haben,
             unbedingt einen <parm> haben mu"ssen.
        Da <parm> mit <nl> abgeschlossen wird, ko"nnen Kommandos  der



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 243 -                    MMMMoooonnnniiiittttoooorrrr


        letztgenannten beiden Gruppen nur am Ende einer Zeile formu-
        liert  werden.   Das  Zeilenende  kann  fu"r  einen  Monitor-
        Parameter nicht durch <backslash><nl> kaschiert werden !

        Eine genaue Darstellung der Verwendung  der  <parm>  in  den
        Monitor-Kommandos ist folgende:
        Zur Auswertung des Kommandoparameters wird die Zeichenkette

                < MACRO( <parm> ) >

        herangezogen.  Input-Text fu"r den Makro-Prozessor  ist  der,
        im  Kommando  formulierte  Text bis zum <nl>.  Beim \branch-
        Kommando mu"ssen beide Parameterteile <b_label> und  <b_expr>
        vor  dem  <nl>  untergebracht  werden.   Vom Output-Text des
        Makro-Prozessors  werden  die  Zeichen  nach  den  fu"hrenden
        <blank>  oder  <tab>  bis  zum  Ende,  aber  maximal nur 100
        Zeichen genommen  (beim  \branch-Kommando  100  Zeichen  fu"r
        beide Parameter).

        Bei der Analyse des Eingabetextes versucht der Monitor jede,
        einem  <backslash>  ("\") folgende Zeichenfolge als Monitor-
        Kommando  zu  interpretieren,  unabha"ngig  davon,   ob   dem
        <backslash> Klammern ( (... oder {... ) oder Quoting-Symbole
        ( "... oder `... oder /*... ) vorausgegangen sind.  Auch die
        Formulierung  von "\\" fu"hrt nur dazu, dass das erste "\" in
        den  Monitor-Puffer  u"bernommen  wird,  dann  aber  die  dem
        zweiten  "\"  folgenden  Zeichen  auf  ein  Monitor-Kommando
        analysiert wu"rden.

        Eine  als   Monitor-Kommando   identifizierte   Zeichenfolge
        gelangt  nicht  in  den  Monitor-Puffer; wohl aber sonst die
        gesamte Zeichenfolge einschliesslich des <backslash>.

        Der Monitor liest seine Kommandos nur aus  dem  Eingabetext;
        er  kann  nicht dazu gebracht werden, den Monitor-Puffer als
        Eingabetext zu lesen.

        _2._4._7.  BBBBeeeesssscccchhhhrrrreeeeiiiibbbbuuuunnnngggg ddddeeeerrrr MMMMoooonnnniiiittttoooorrrr----KKKKoooommmmmmmmaaaannnnddddoooossss

        Der folgende Abschnitt  beschreibt  die  einzelnen  Monitor-
        Kommandos.      Die     Kommando-Schreibweise     in     den
        Zwischenu"berschriften ist als plausible Abku"rzung  der  vorn
        exakt definierten Notation zu verstehen.

        _2._4._7._1.  AAAAppppppppeeeennnndddd


        \a
        \append

             Eine ggf.  eingetragene  Lo"schvormerkung  des  Monitor-
             Puffers  (autoclear_mode)  wird ausgetragen, sodass ein
             folgender Eingabetext - jedenfalls beginnend  als  neue
             Zeile - dem bisherigen Monitor-Puffer angefu"gt wird.

        _2._4._7._2.  BBBBrrrraaaannnncccchhhh


        \b <b_parm>
        \branch <b_parm>



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 244 -                    MMMMoooonnnniiiittttoooorrrr


                  <b_parm> =
                          {<blanc>|<tab>} ["?"<b_expr>]
                          {<blanc>|<tab>} <b_label> <nl> ;

             Durch  das  Kommando   erfolgt   ein   bedingter   oder
             unbedingter  Sprung  im  Eingabetext.   Die  Ausfu"hrung
             eines Sprungs wird mit der Meldung

                            "Kein Sprung am Terminal"

             abgelehnt, wenn der Eingabetext  vom  Terminal  gelesen
             wird.   Andernfalls  wird im Falle eines auszufu"hrenden
             Sprungs im Eingabetext - also im  included_file  -  die
             Marke

                                    \k <mark>

             gesucht (s. \k-Kommando), fu"r die

                            <MACRO(<label>)> = <mark>

             ist.   Wird   eine   solche   Marke   gefunden,    wird
             anschliessend  die  Eingabe  des Eingabetextes mit der,
             dieser Marke folgenden Textposition  fortgesetzt.  Wird
             keine  solche  Marke  gefunden,  wird  versucht,  einen
             Sprung

                                \branch {default}

             auszufu"hren. Gelingt auch das  nicht  (weil  der  Makro
             "{default}"  nicht definiert ist, oder im included_file
             nicht addressiert), wird darauf mit der Meldung

                          " ? Label <MACRO(<b_label>)>"
                 " ? Label < MACRO ({default}) > ({default}) "

             hingewiesen und  das  included_file  folgend  verlassen
             (folgend  wird  aus  dem  Eingabetext <EOF> gelesen (s.
             \include-Kommando)).

             Ein unbedingter Sprung ohne die Angabe "?"<b_expr> wird
             in   jedem   Falle  auszufu"hren  versucht.   Bei  einem
             bedingten Sprung wird der Ausdruck

                                <MACRO(<b_expr>)>

             ausgewertet.   Dieser  Ausdruck  darf  Operatoren   und
             Operanden enthalten.  Operatoren sind:

                     **         Potenzieren
                     - !        Vorzeichen, logische Negation
                     * / %      Multiplikation, Division, Divisionsrest
                     + -        als zweistellige Operationen
                     > >= < <=  Vergleichsoperatoren
                     = !=       Gleichheit, Ungleichheit
                     &          logisches UND
                     |          logisches inclusives ODER


             Operationen  auf  gleicher  Zeile  sind  von   gleicher



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 245 -                    MMMMoooonnnniiiittttoooorrrr


             Bindungssta"rke,    sonst   gilt   absteigende   Bindung
             entsprechend der Aufza"hlung zur Festlegung der  Bindung
             von Operationen.

             Der Ausdruck darf als  Operanden  nur  noch  ganzzahlig
             numerische Werte mit einem Wertebereich zwischen -32768
             bis 32767 enthalten, sonst erfolgt nach  entsprechenden
             Meldungen  (s.  unten)  ein  Abbruch  der weiteren Aus-
             drucksberechnung.  Die Ausdrucksauswertung  wird  durch
             die Zeichen

                         <blank>, <tab>, <nl> oder <eof>

             beendet.

             Die arithmetischen Operationen werden in u"blicher Ganz-
             zahlarithmetik   (/:   ganzer  Teil  der  Division,  %:
             Divisionsrest; Division durch 0 ergibt nach Warnung den
             Wert   0)   berechnet.   Die  logischen  Operationen  (
             !,=,>,<,| ) deuten bei ihren Operanden  <=0  als  FALSE
             und  >0  als  TRUE.   Die logischen Operationen und die
             Vergleichsoperationen liefern den arithmetischen Wert 0
             fu"r  FALSE  und  1  fu"r  TRUE.  Die Ausdrucksberechnung
             erfolgt von links nach rechts,  entsprechend  den  Bin-
             dungsregeln,  geklammerte  Teile werden ge- und entkel-
             lert.

             Bei der Ausdrucksauswertung (nach Makro-Auflo"sung) wer-
             den folgende Fehler im Ausdruck erkannt:

                        zusa"tzliche schliessende Klammern
                        am Ende werden ignoriert

                        zusa"tzliche o"ffnende Klammern
                        am Ende, ergeben 0 als Ausdruckswert

                        der Ausdruck ist leer,
                        sein Wert ist 0

                        der Ausdruck entha"lt nur das
                        nicht akzeptable Zeichen <c>,
                        sein Wert wird 0

                        das gefundene <c> ist kein Operator
                        der Wert wird 0

                        Division durch 0 ergibt den Wert 0

             Ein bedingter Sprung wird ausgefu"hrt, wenn die  Auswer-
             tung des Ausdrucks einen Wert > 0 erbringt. Andernfalls
             wird die Eingabe  des  Eingabetextes  hinter  <b_label>
             folgend fortgesetzt.

        _2._4._7._3.  CCCChhhhddddiiiirrrr


        \cd <parm>
        \chdir <parm>





        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 246 -                    MMMMoooonnnniiiittttoooorrrr


             Das  vom  Nutzer  bei  Start   von   ING_DB   von   ihm
             eingestellte  working_directory bleibt auch wa"hrend der
             Arbeit von ING_DB  erhalten.   Unter  diesem  Pfadnamen
             bestimmte  Files  werden  im  Unterschied zu dem, durch
             {Pathname} mit "ing_db" symbolisierten Files, in diesem
             Kapitel als

                     <user_cd> / <file_name>

             symbolisiert.

             Das fu"r den Nutzer vor Start  von  ING_DB  eingestellte
             working_directory   wird   durch   das  \chdir-Monitor-
             Kommando auf

                     <user_cd> = <MACRO(<parm>)>

             vera"ndert; u"ber einen Misserfolg dabei  informiert  die
             Meldung

                  "cannot access directory  <MACRO(<parm>)>  "

             Der Monitor meldet sich nach Kommando-Ausfu"hrung wieder
             mit einer Prompt-Meldung "ING_db>" oder "ING_db:".

        _2._4._7._4.  EEEEddddiiiittttoooorrrr


        \e [<parm>]
        \ed [<parm>]
        \edit [<parm>]
        \editor [<parm>]

             Es wird ein Editor aus dem File

                               <MACRO("{editor}")>

             zu laden versucht.  Ist der Makro nicht definiert, wird
             gleich  ein installationsabha"ngiger System-Editor, z.B.
             eeeedddd,,,, vvvviiii,,,, rrrraaaannnndddd,,,, geladen. Gelingt das nicht, erfolgt  eine
             Fehlerausschrift.   Ausserdem  wird  der  Makro {error-
             count} mit dem Wert -1 gefu"llt und der Macro {exectrap}
             mit der Meldung

                                  "edit: exec"

             ausgefu"hrt.

             Der Monitor meldet

                            ">> <editor_file_name> "

             Danach arbeitet man unter Steuerung des geladenen  Edi-
             tors, ihm wird als Parameter

                                 <MACRO(<parm>)>

             oder falls das Kommando  keinen  Parameter  hatte,  der
             File-Name des Monitor-Puffers u"bergeben.  Das bedeutet,
             dass der Editor  das  File  la"dt  und  als  currentfile



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 247 -                    MMMMoooonnnniiiittttoooorrrr


             einstellt.

             Im Falle der Arbeit auf dem Monitor-Puffer  kommen  mit
             dem  Editor  ausgefu"hrte  A"nderungen  nur dann dort an,
             wenn dem  Editor  ein  w-Editor-Kommando  vor  A"nderung
             seines  currentfile  gegeben  wird. Jedenfalls wird bei
             Ausfu"hrung   eines   \e-Monitor-Kommandos   eine   ggf.
             eingetragene  Lo"schvormerkung  fu"r  den  Monitor-Puffer
             (autoclear_mode) ausgetragen.

             Natu"rlich kann nach der Arbeit auf  dem  Monitor-Puffer
             oder  u"berhaupt  auch in anderen Files editiert werden.
             Beachten sie bei der Formulierung von File-Namen,  dass
             user_cd   als  current_directory  (s.  \chdir-Kommando)
             eingestellt ist.

             Nach einem q-Editor-Kommando fu"r den System-Editor oder
             einer  anderen Beendigung des geladenen Editors erfolgt
             die Ru"ckkehr zum ING_DB -Monitor.  Der Monitor ruft fu"r
             den  Fall,  dass  der  Editor  einen  Ru"ckkehrcode != 0
             lieferte, den Makro {exectrap}. Vorher wird  der  Makro
             {errorcount}  mit  dem exit-Status des Editors gefu"llt.
             Das erfolgt  so,  als  ga"be  man  selbst  das  Monitor-
             Kommando

                                 {exectrap}\eval


        _2._4._7._5.  GGGGoooo


        \g
        \go

             Mit  diesem   Kommando   werden   QUEL-Statements   zur
             Ausfu"hrung   angewiesen.    Der   Monitor   zeigt   die
             Kommandou"bernahme mit der Prompt-Meldung

                               "I N G - d b . . ."

             an und beendet  damit  seinen  Eingabe-Status  fu"r  die
             Dauer   der   Arbeit   des   Parsers   und  der  diesem
             nachgelagerter Prozesse.

             Dem Parser wird die  vom  Makro-Prozessor  verarbeitete
             Verkettung folgender Texte u"bergeben:

                     < MACRO ( <MACRO("{begintrap}")>,
                               <Monitor-Puffer>,
                               <MACRO("{endtrap"})> ) >

             Man achte darauf, dass der Monitor-Puffer so  bereinigt
             wurde,  dass  dem  Parser nur QUEL-Statements u"bergeben
             werden, er signalisiert sonst Fehler.

             Nachdem  die  Arbeit  des  Parsers  und  dessen   nach-
             gelagerter   Prozesse  bei  der  Ausfu"hrung  der  QUEL-
             Statements beendet ist, arbeitet  der  Monitor  weiter.
             Der  Monitor  u"bernimmt  N  als Anzahl der bearbeiteten
             Tupel und definiert den Makro {tuplecount} als



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 248 -                    MMMMoooonnnniiiittttoooorrrr



                            {define; {tuplecount}; N}

             Der Monitor arbeitet den Makro {continuetrap}  ab,  als
             ha"tte man das Monitor-Kommando

                              {continuetrap} \eval

             (s. Makroprozessor) gegeben. Der  Monitor  zeigt  seine
             Eingabebereitschaft    durch    die    Prompt-Meldungen
             "ING_db>" oder "ING_db:" an.

             Nach einem \go-Kommando ist der Monitor-Puffer zuna"chst
             noch  unvera"ndert;  er ist jetzt aber zur Lo"schung vor-
             gemerkt (autoclear_mode).  Diese  Lo"schvormerkung  wird
             durch die Option "-a" unterdru"ckt.

             Wenn die Ero"ffnung des Monitor-Puffers fu"r  den  Makro-
             Prozessor  nicht gelingt, erfolgt ein Systemabbruch mit
             der Meldung

                                  "go: open 1"


        _2._4._7._6.  HHHHeeeellllpppp


        \h [<parm>]
        \help [<parm>]

             Der Monitor wa"hlt mit Angabe <parm> aus ../sys/ref  die
             Kurzdokumentation zum ING_DB -Kommando und schreibt auf
             "std_out".  Ohne  <parm>  wird  das  Inhaltsverzeichnis
             ausgegeben.

        _2._4._7._7.  IIIInnnncccclllluuuuddddeeee uuuunnnndddd RRRReeeeaaaadddd


        \i <parm>
        \include <parm>
        \read <parm>

             Dem Monitor wird das File

                     <user_cd> / <MACRO(<parm>)>

             als Eingabetextspender zugeordnet. Das  Kommando  wirkt
             wie ein Sprung an den Anfang dieses File.

             Fehlt <parm> oder ist <MACRO(<parm>)> leer,  wirkt  das
             Kommando  so, dass das folgende Zeichen des dem Monitor
             angeschlossenen Eingabetextes <eof> wird.   Das  bedeu-
             tet,  dass ein included_file folgend verlassen wird; in
             der Basis-Terminal-Ebene  tritt  der  Effekt  wie  nach
             einem \quit-Kommando ein.

             Andernfalls wird das durch <MACRO(<parm>)>  bezeichnete
             File  zum  ku"nftigen Eingabetextspender fu"r den Monitor
             (es sei denn die Meldung




        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 249 -                    MMMMoooonnnniiiittttoooorrrr



                      "open INCLUDE file <MACRO(<parm>)> "

             zeigt den Abbruch der Kommandobearbeitung an).  Solange
             der   Monitor  "file-gesteuert"  arbeitet,  werden  die
             Prompt-Meldungen wie  durch  die  ING_DB  -Option  "-s"
             unterdru"ckt.

             Fu"r die Funktions-Makros {read...}, {readdefine...} (s.
             Makro-Prozessor)  bleibt  auch  bei dieser Arbeitsweise
             des Monitor das Terminal (genauer  standard_input)  das
             Eingabemedium.

             Das angeschlossene File darf weitere \include-Kommandos
             enthalten;  diese  sind bis zu einer Schachtelungstiefe
             von 5 (diese Anzahl ist generierungsfa"hig) hierarchisch
             hintereinander  liegender  \include-Kommandos  erlaubt.
             Ggf. erfolgt eine Kommandoabweisung durch die Meldung

                             "Mehr als 5 INCLUDE'S"

             Liest der Monitor aus dem included_file <eof>  (nachdem
             es  sequentiell  durchlesen wurde, oder bei Nichterfolg
             eines dort  enthaltenen  Monitor-Kommandos),  wird  das
             File  verlassen;  die  Monitoreingabe wird mit dem Text
             des File hinter  dem  letztwirksamen  \include-Kommando
             fortgesetzt.

             Bei Ru"ckkehr in die  Basis-Terminal-Ebene  meldet  sich
             der Monitor - falls nicht "-s" gesetzt war - wieder mit
             einer Prompt-Meldung  "ING_db>"  oder  "ING_db:".   Die
             Abgabe  eines <eof> in der Basis-Terminal-Ebene hat die
             gleiche Wirkung  wie  das  \quit-Kommando:  die  ING_DB
             -Sitzung wird synchron beendet.

             Ist <MACRO(<parm>)> das einzelne Zeichen  "-",  erfolgt
             die Meldung

                                   "<Eingabe>"

             und der  ku"nftige  Eingabetext  fu"r  den  Monitor  wird
             wieder  vom  Terminal (standard_input) gelesen. Das ist
             nicht die  oben  erwa"hnte  Basis-Terminal-Ebene;  durch
             Abgabe  eines <eof> vom Terminal erfolgt kein Sitzungs-
             abbruch, sondern es wird wieder  das  File  zum  Einga-
             betextspender,  aus dem das "\include -" abgesetzt wor-
             den  war.   Das   ero"ffnet   die   Mo"glichkeit,   unter
             grundsa"tzlicher  Steuerung  durch  ein  File, zwischen-
             zeitlich in freiem Format vom Terminal  zu  lesen.  Das
             Nachrichtenlevel  fu"r  die  Promptmeldungen  ("-s" oder
             nicht) ist wa"hrend dieser Arbeit am Terminal wieder so,
             wie fu"r die ING_DB -Sitzung eingestellt.

        _2._4._7._8.  MMMMaaaarrrrkkkk


        \k <parm>
        \mark <parm>





        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB





        Anwendung                 - 250 -                    MMMMoooonnnniiiittttoooorrrr


             Der Eingabetext entha"lt eine Marke als Zielangabe eines
             ggf.  auszufu"hrenden  \branch-Kommandos.   Das Kommando
             selbst  ist  wirkungslos.   Der  Eingabetext  wird  bis
             hinter  <parm>  u"berlesen; der Monitor-Puffer wird fol-
             gend  jedenfalls   mit   einer   neuen   Zeile   weiter
             beschrieben,  der  Monitor meldet sich wieder mit einem
             Prompt-Symbol.    Anla"sslich   der   Ausfu"hrung   eines
             \branch-Kommandos   wird  das  included_file  von  vorn
             beginnend nach der zutreffenden Marke abgesucht.

        _2._4._7._9.  LLLLiiiisssstttt


        \l
        \list

             Der  vom  Makro-Prozessor  aus  dem  verketteten   Text
             erzeugte Text

                        < MACRO( <MACRO("{begintrap}")>,
                                 <Monitor-Puffer>,
                                 <MACRO("{endtrap}")> ) >

             wird auf dem Terminal angelistet.  Man  erha"lt  dadurch
             Auskunft, welcher Text tatsa"chlich dem Parser mit einem
             \go-Kommando angeboten wu"rde.  Weiterhin  werden  durch
             die  Arbeit  des  Makro-Prozessors die Funktions-Makros
             (s. Makro-Prozessor)  bearbeitet.   Der  Monitor-Puffer
             bleibt  unvera"ndert.   (Achtung:  Dadurch, dass bei der
             ersten Verwendung  des  Kommandos  ggf.  Substitutions-
             Makros definiert werden, kann die wiederholte Anwendung
             des Kommandos andere Ergebnisse bringen.)

             Eine  ggf.   eingetragene   Lo"schvormerkung   fu"r   den
             Monitor-Puffer wird ausgetragen (autoclear_mode).

        _2._4._7._1_0.  MMMMoooonnnniiiittttoooorrrr

        Mit dem Monitor-Kommando la"sst sich das standardma"ssige Kom-
        mandokennzeichen   """"\\\\""""   umdefinieren.  Fehlt  das  Argument
        <parm>, wird wieder auf den Standard zuru"ckgeschaltet.
        Die Neudefinition des Kommandokennzeichens sollte  nur  dann
        vorgenommen  werden,  wenn  das  Zeichen  """"\\\\"""" nicht oder nur
        umsta"ndlich erreicht werden kann.
        Es wird darauf hingewiesen, dass bei Neudefinition des  Kom-
        mandokennzeichens  Monitor-Kommandodateien  unter  Umsta"nden
        nicht mehr abarbeitungsfa"hig sind.

        _2._4._7._1_1.  PPPPrrrriiiinnnntttt


        \p
        \print

             Der Inhalt des Monitor-Puffers  wird  ohne  Vera"nderung
             durch  den Makro-Prozessor auf dem Terminal angelistet.
             Eine  ggf.   eingetragene   Lo"schvormerkung   fu"r   den
             Monitor-Puffer  wird ausgetragen (autoclear_mode).  Der
             Monitor meldet sich nach Kommandoausfu"hrung wieder  mit
             einer Prompt-Meldung "ING_db>" oder "ING_db:".



        ING_DB 6.3/3           Juni 16, 1989                  IIIINNNNGGGG____DDDDBBBB


