Matthias Watermann
Berlin

 







Erstellung einer Datenbank
zur Verwaltung
von Dokumenten
(Bücher, Zeitungen, Zeitschriften)










Projektarbeit zum Kurs
Oracle (I)
im Februar 2001












  1. Projektbeschreibung

    1. Einordnung des Themas / Anwendungsbereiche

      Zur praktischen Anwendung des während des Seminares zum Thema "Oracle I" Erlernten soll eine angemessene Datenbank-Struktur entwickelt werden. Um die Aufgabe im Rahmen der zur Verfügung stehenden Zeit bewältigen zu können, mußte sie auf einen Kern reduziert werden, der lediglich die verschiedenen Aspekte einer DB-Anwendung gewissermaßen beispielhaft demonstriert.

    2. Aufgabenstellung

      Die Wahl fiel auf eine Anwendung, die es ermöglichen soll, die Dokumente einer Präsenzbibliothek zu verwalten.

      "Präsenzbibliothek" soll in diesem Zusammenhang bedeuten: Eine Dokumenten-Sammlung, deren Bestandteile (eben die verwalteten Dokumente) ständig vorhanden sind. Damit entfällt v.a. der gesamte Komplex einer Ausleihen-Verwaltung, wie er im ursprünglichen DB-Modell noch enthalten war.

      Daneben wird unterstellt, jedes Dokument sei lediglich ein einziges Mal vorhanden, wodurch auf die Verwaltung ggf. mehrerer Exemplare verzichtet werden kann.

    3. Ziel-Beschreibung

      Ergebnis der Bemühungen soll sein eine Datenbank, die aufgrund ihrer Struktur in der Lage ist, die Bedürfnisse einer kleinen Bibliothek - etwa im heimischen Wohn- und Arbeits-Zimmer oder der kleinen Firmen-Bibliothek - zu befriedigen. Daraus ergibt sich nicht nur, daß unterschiedliche Arten von Dokumenten erfaß- und auffindbar sein müssen, wie beispielsweise neben Monographien auch Zeitschriften- und Zeitungs-Titel. Vielmehr soll die zu entwerfende Struktur der einzelnen Tabellen die wesentlichen Angaben zur formalen Erschließung enthalten, wie sie etwa in der DIN 1505 definiert sind.

  2. Problem-Analyse

    1. Die relevanten Objekte

      Objekt Bedeutung
      Dokument ein Buch, eine Zeitung oder Zeitschrift
      Verlag Herausgeber des Werkes
      Autorin Verfasserin des Werkes
      Sprache (Haupt-)Sprache des Werkes
      Sachgebiet inhaltl. Einordnung innerhalb der Bibliothek
      Dokument-Typ Art des Dokumentes (z.B. Buch/Zeitung/Zeitschrift)


      1. Beschreibung

        In der folgenden Tabelle sind die einzelnen Entitäten mit ihren jeweiligen Attributen zusammengestellt:

        Objekte Attribute Bemerkungen Beispieldatum atomarer Wert
        Dokument Autorin   Wolters, Enno Text[80]
          Sachtitel   Programmieren in MUMPS Text[255]
          Untertitel   Mit zahlr. Übungsbeispielen Text[255]
          Ausgabe-Bezeichnung   1. Aufl. Text[80]
          Erscheinungs-Jahr   1988 Datum (JJJJ)
          Erscheinungs-Ort   München, Wien Text[80]
          Verlag   Hanser Text[80]
          Bestell-Nummer ISSN, ISBN 3-446-15271-7 Text[13]
          Umfang Seiten-Zahl 224 positive Ganzahl
          Anschaffungs-Datum Gestehungs-Datum (ISO-Format) 1988-12-12 Datum
          Preis Anschaffungs-Preis 29,80 positive Bruchzahl
          Sachgebiet Zuordnung in der Bibliothek IuK, Grundlagen/Forschung Text[80]
          Sprache DIN 3166 deutsch Text[20]
          Dokument-Typ   Buch Text[20]
          Signatur eindeutige Kennzeichnung innerhalb der Bibliothek Ig.de.Bu/1988-20 Text[20]
          Abstract kurze inhaltl. Zusammenfassung   Text[{endlos}]
          Erscheinungsweise nur bei Zt/Zs wöchentlich Text[40]
        Autorin Nachname   Wolters Text[80]
          Vorname   Enno Text[40]
        Verlag Name   Carl Hanser Verlag Text[80]
          Ort Verlags-Sitz München, Wien Text[80]
          URI Internet-Adresse http://www.hanser.de/ Text[255]
        Sprache Bezeichnung Sprachen-Name deutsch Text[20]
          Kürzel ISO-/DIN-Kode 
        (für Signatur)
        de Text[3]
        Sachgebiet Bezeichnung   IuK, Grundlagen/Forschung Text[80]
          Kürzel (für Signatur) Ig Text[2]
        Dok-Typ Bezeichnung   Buch Text[20]
          Kürzel (für Signatur) Bu Text[2]
    2. Beziehungen zwischen den Objekten

      Die folgenden Feststellungen sind eben dies: Fest-Stellungen. Mit anderen Worten: Die folgenden Punkte sind nicht nur Definitionen sondern zugleich auch Einschränkungen der "realen Welt" zum Zwecke der durchsichtigeren Modellierung.

      • Jedes Dokument erscheint in einem Verlag.

      • Jeder Verlag kann mehrere Dokumente publizieren.

      • Jedes Dokument kann einen oder mehrere Autorinnen haben.

      • Jede Autorin kann an einem oder mehreren Dokumenten mitwirken.

      • Jedes Dokument ist in einer (Haupt-)Sprache erschienen.

      • Jede Sprache kann in mehreren Dokumenten verwendet werden.

      • Jedes Dokument ist einem Sachgebiet zugeordnet.

      • Jedes Sachgebiet kann von mehreren Dokumenten verwendet werden.

      • Jedes Dokument repräsentiert einenDokumenten-Typ.

      • Jeder Dokumenten-Typ kann von mehreren Dokumenten verwendet werden.

    3. Weitere Erwägungen

      Obgleich die Signatur eines Werkes quasi einen "errechneten Wert" darstellt (zusammengesetzt aus Sprache, Sachgebiet, Dokument-Typ, Anschaffungs-Jahr und lfd. Nummer) wird sie einzeln verwaltet. Damit ist sichergestellt, daß sie unverändert bleibt, selbst wenn später die Bezeichnungen der implizit referenzierten Daten geändert werden.

  3. Das Entity-Relationship-Model

    Zunächst muß analysiert werden, welche Ebenen der Verallgemeinerung es bei den zu verarbeitenden Dokumenten gibt. Dabei entsteht eine Art Objekt Hierachie:

    Bücher Datenträger Zeitungen Zeitschriften
    Unikate Periodika
    Grunddaten (die zu allen Dokumenten gehören)

    Eine erste graphische Umsetzung der Beziehungen zwischen den verschiedenen Objekten vermittelt den Eindruck eines bereits recht hohen Komplexitäts-Grades.

    Alldieweil die Komplexe "Datenträger-Verwaltung (CDs)" sowie "Telefon-Nummern (Vorwahlen)" im Rahmen dieser Arbeit unwesentlich sind, fallen sie im Zuge einer Reduktion weg. Unter dem Aspekt des DB-Designs stellen sie keine neuen/zusätzlichen Konstrukte dar. Damit haben wir nun jenes ER-Modell, welches im weiteren implementiert werden soll mit den Entitäten

    1. Dokument

    2. Sprache

    3. Sachgebiet

    4. Dokument-Typ

    5. Verlag

    6. Postleitzahl

    7. Ortsname

    8. Unikat (is-a Dokument)

    9. Buch (is-a Unikat)

    10. Periodikum (is-a Dokument)

    11. Erscheinungs-Rhythmus

    12. Autorin

    Im Grunde könnten "Buch" und "Unikat" hier zusammengefaßt werden, wodurch die – sagen wir: – Verschachtelungs-Tiefe sowohl der ERM-Darstellung wie auch einer späteren DB-Struktur geringer würde. Um gleichwohl die Möglichkeit offen zu halten, später den hier weggefallenen "CD-Ast" wieder einzuhängen, soll diese vermeintlich umständliche Aufteilung/Trennung beibehalten werden.

    Ähnliches scheint auch für die Trennung von "Postleitzahl" und Ort "Ortsname" zu gelten: Durch die einstweilige Streichung der Anbindung von Telefon-Vorwahlen könnten die beiden übriggebliebenen Entitäten zusammengefaßt werden. Doch würde das nicht nur dazu führen, die spätere (Rück-)Integration der Telefon-Vorwahlen zu erschweren, sondern zudem bedeuten, eine massive Daten-Redundanz einzuführen (ein Ortsname kann bei etlichen Postleitzahlen auftauchen). Daher bleibt’s auch hier bei der dargestellten Aufteilung.

  4. Überführung des ER-Modells
    in das Relationen-Modell

    Bei der Umformung des ER-Modells in die Modellierung von Relationen geht die unmittelbar visuelle Repräsentation der Beziehungen verloren. Stattdessen finden wir hier im Prinzip bereits die Struktur-Definitionen der späteren DB-Tabellen.

    Alle Entitäten des ERM tauchen hier als sog. Relationen mit ihren Attributen wieder auf. Neu hinzugekommen sind in den meisten Relationen die expliziten Fremdschlüssel-Attribute, welche im ERM lediglich implizit durch die jeweiligen graphisch dargestellten Beziehungen ausgedrückt waren:

    Relation Primär-Schlüssel Fremd-Schlüssel Bezug auf Beziehung
    Dokument DokID      
        Sprach-Kürzel Sprache N:1
        Sachgebiets-Kürzel Sachgebiet N:1
        DokTyp-Kürzel Dokument-Typ N:1
        Verlags-ID Verlag N:1
    Sprache Kürzel      
    Sachgebiet Kürzel      
    Dokument-Typ Kürzel      
    Verlag ID      
        PLZ Postleitzahl N:1
    Postleitzahl PLZ      
        Orts-ID Orte N:1
    Orte ID      
    Unikat DokID DokID Dokument 1:1
    Buch DokID DokID Unikat 1:1
    Periodikum DokID DokID Dokument 1:1
        Erscheinungs-ID Erscheinungsweise N:1
    Erscheinungsweise ID      
    Autorin ID      
    Dok-Autor ID      
        Autor-ID Autorin N:M
        DokID Unikat/Periodikum N:M


  5. Die Normalisierung der Relationen

    Die erste Normalform ("alle Attribute besitzen atomare Werte") ist im vorliegenden Modell bereits gegeben. Das Gleiche gilt auch für die zweite ("jedes Nicht-Schlüssel-Attribut ist funktional abhängig von allen Schlüssel-Attributen") und dritte ("alle Nicht-Schlüssel-Attribute sind voneinander unabhängig") Normalform.

    Der in Verlag, Unikat und Periodikum enthaltene URI (Uniform Resource Identifier) könnte im Einzelfall gegen die dritte Normalform verstoßen, etwa wenn es bei einem bestimmten Verlag eine 1:1-Entsprechung von ISBN und Web-URL geben sollte. Die geringe Wahrscheinlichkeit einer solchen Situation (unabhängig von ihrer Sinnhaftigkeit und Zweckmäßigkeit) rechtfertigt es jedoch m.E. (aus Platz- wie auch Performance-Gründen) nicht, eine seperate URI-Relation zu bilden.

    Die im Vergleich zum ER-Modell neu entstandene Relation Dok-Autor realisiert die beiden N:M -Beziehungen zwischen Autorin und Unikat bzw. Periodikum. Da für die beiden Fremdschlüssel im realen Betrieb ohnehin eigene Datenpfade (d.i. Indizes) gepflegt werden müssen, habe ich den Primär-Schlüssel dieser Hilfs-Relation als eigenes, unabhängiges Attribut definiert, das keinem weiteren Zwecke dient, sondern lediglich die Verwaltung eines zusammengesetzten Primär-Schlüssels vermeiden soll.

    Bemerkenswert ist noch die dokID in den Relationen Unikat, Buch sowie Periodikum, denn hier dient dieses Attribut sowohl als Primär- wie auch Fremd-Schlüssel. Auf diese Weise soll die inhaltliche Integrität der zusammengehörenden Daten sichergestellt werden.

  6. Die Datenbank-Struktur

    1. Der Aufbau der Tabellen

      Die Tabellen-Definitionen ergeben sich unmittelbar aus dem zuvor erstellten Relationen-Modell. Hinzu kommt in diesem Entwicklungs-Schritt lediglich die Deklaration der für die einzelnen Datenfelder jeweils verwendeten Daten-Typen, wie sie aus den folgenden Kode-Fragmenten ersichtlich sind.

    2. Das Anlegen der Tabellen

      Die komplette Tabellen-Struktur wird in mehreren, logisch aufeinanderfolgenden Arbeitsschritten erzeugt. Eine passende BATch-Datei automatisiert die dafür notwendigen Schritte weitestgehend. Nacheinander werden dadurch u.a. die folgenden SQL-Skripte ausgerufen:

      Bei der Festlegung der Daten-Typen und ihrer jeweiligen Werte-Bereiche wurden ein paar selbstgesetzte Regeln angewendet:

      • Zeichen-Felder (Strings) werden als CHAR deklariert, wenn ihr späterer Inhalt eine feste Länge besitzt, so daß der DB-interne Verwaltungs-Aufwand insofern minimiert wird. Wird der erwartete, konkrete Feld-Inhalt hingegen unterschiedlich lang sein, wird der Daten-Typ VARCHAR2 verwendet, um den benötigten Speicherplatz möglichst effektiv zu nutzen.

      • Jene ID-Felder, die letzten Endes bloß der internen Verknüpfung der verschiedenen Tabellen dienen, und die ihren Wert später über einen Sequenz-Wert erhalten, sind als NUMBER(28) deklariert, um so den gesamten, von einer Sequenz zur Verfügung gestellten Werte-Bereich ausnutzen zu können.

      • Pflicht- und optionale Felder (bzw. deren Inhalte) sind explizit als NOT NULL bzw. NULL deklariert.

      • Bei der Benamsung der Datenfelder soll die "Zugehörigkeit" des Feldes zu einer Tabelle durch ein kurzes Präfix signalisiert werden. So beginnen etwa die Feldnamen in der Tabelle mit den allgemeinen Dokumenten-Angaben einheitlich mit dok , jene in der Verlags-Tabelle mit vlg oder jene in der Tabelle der Periodika mit pe usw.usf.

      • Die Benamsung der DB-Objekte ist ähnlich typisiert: Tabellen beginnen mit dem Präfix Tbl , Indizes mit Idx , Sequenzen mit Seq , Trigger mit Trg . Primär-Schlüssel Einschränkungen (Constraints) beginnen mit pk , Fremdschlüssel-Einschränkungen mit fk , jeweils gefolgt vom Namen der Tabelle und dem Namen des verwendeten Schlüssel-Feldes.

      1. Erzeugen der Tabellen

        In einem ersten Schritt werden die "nackten" Tabellen erzeugt, ohne ihre wechselseitigen Beziehungen jetzt schon weiter zu berücksichtigen. Lediglich Daten-Typ sowie ggf. Werte-Bereich der (später) korrespondierenden Felder sind aufeinander abgestimmt.

        Nach dem Abarbeiten dieser SQL-Anweisungen gibt es alle benötigten Tabellen in der Datenbank. Allerdings ist diese Tabellen-Struktur noch in einem wenig brauchbaren - weil: unsicheren - Zustand. Es gibt keinerlei Bezüge zwischen den einzelnen Tabellen, sie existieren gleichsam beziehungslos nebeneinander. Zudem wäre auch der Datenzugriff relativ gemächlich, da es bislang keine Indizes gibt, die den Zugriff beschleunigen könnten.

      2. Erzeugen der Indizes

        Nun werden (1.) die Primär-Schlüssel der einzelnen Tabellen festgelegt, (2.) Indizes angelegt für jede Datenfelder, die einen Fremd-Schlüssel aufnehmen sollen oder (3.) eindeutige Werte enthalten sollen, ohne Primär- oder Fremd-Schlüssel zu sein.

        Die Tabellen sind nun insoweit "sicherer" geworden, als durch die Definition von Primär- und Unique-Schlüssel zumindest die Eingabe von Duplikaten ausgeschlossen wird. Noch immer aber existieren keine formal ausgedrückten Beziehungen zwischen den einzelnen Tabellen bzw. ihren Feldern.

      3. Erzeugen der Beziehungen

        Durch die explizite Definition von Fremd-Schlüsseln werden dem DBMS nun die Verknüpfungen der verschiedenen Tabellen untereinander mitgeteilt. - Zu beachten ist hier die letzte Fremd-Schlüssel Verknüpfung:

        /****
        Alter Table TblDokAutor ADD
                CONSTRAINT fk_DokAutor_BuchID
                Foreign Key(dokID)
                References TblBuch(dokID);
        
        Alter Table TblDokAutor ADD
                CONSTRAINT fk_DokAutor_PeriID
                Foreign Key(dokID)
                References TblPeriodikum(dokID);
        ****/
        
        Alter Table TblDokAutor ADD
                CONSTRAINT fk_DokAutor_dokID
                Foreign Key(dokID)
                References TblMediaBase(dokID);
        

        Autorinnen sollen sowohl für Bücher (Unikate) als auch für Zeitungen/Zeitschriften (Periodika) eingetragen werden können. Mit anderen Worten: Das dokID-Feld der Tabelle TblDokAutor soll entweder auf ein korrespondierendes Feld der Tabelle TblBuch verweisen oder auf ein solches der TblPeriodikum-Tabelle.

        Der Versuch, dies durch zwei Fremd-Schlüssel Definitionen für das Feld auszudrücken (im oben auskommentierten Kode-Teil), führt indes praktisch zu einer Sowohl-als-auch-Verknüpfung, d.h. ein Satz in TblDokAutor muß sowohl TblBuch referenzieren als auch zugleich TblPeriodikum - mithin nicht das, was beabsichtigt war.

        Der gewünschte Effekt kann indes erreicht werden, indem diese "Zwischen-Tabelle" mit TblMediaBase verknüpft wird. Eine derart veränderte Anbindung der AutorInnen im ER-Modell verringert zugleich ein wenig die Komplexität der Beziehungen in Vergleich zum vorherigen Modell. An dem aktuellen Relationen-Modell sind in diesem Zusammenhang keine Änderungen nötig, da die konkreten Beziehungen dort ohnehin keinen direkten Ausdruck finden.

      4. Erzeugen referentieller Integrität

        Um Konsistenz wie Integrität der Daten zu gewährleisten, sowie auch um die spätere Benutzerin vor der Berücksichtigung von Daten zu bewahren, die lediglich zur DB-internen Verwaltung benötigt werden (v.a. die verschiedenen ID-Felder der einzelnen Tabellen), wird nun eine Reihe von zusätzlichen Objekten erzeugt. Die Sequenzen dienen dazu, Werte für die ID -Felder neuer Datensätze zu liefern, die Trigger sollen dies, sowie eine gewisse Fehler-Prüfung erledigen.

        Zu diesem Zeitpunkt stehen nun alle wesentlichen Strukturen und Objekte zur Verfügung, um mit den Tabellen zu arbeiten. Mithilfe der verschiedenen Trigger wird zumindestes eine rudimentäre Daten-Prüfung realisiert, um grobe Fehleingaben abzufangen und die Design-Entscheidungen zu erzwingen.

        Gleichwohl bleibt - aus Sicht der Anwenderin - die Benutzung der Tabellen-Struktur noch einigermaßen umständlich: Um Real-Daten einzugeben (z.B. die bibliographischen Angaben zu einem konkreten Buchtitel), müssen die implementierten Beziehungen zwischen den einzelnen Tabellen bekannt sein und angemessen berücksichtigt werden.

      5. Realisierung des Datenzugriffs

        Mithilfe der sogenannten Views können Datenfelder, die ihren Ort in verschiedenen Tabellen haben, in einer gemeinsamen Ansicht dargestellt und so der Anwenderin zur Verfügung gestellt werden. In einem ersten Schritt wird eine solche Ansicht definiert, die lediglich einen Lese-Zugriff gestattet.

        Mithilfe dieser Ansicht können die erfaßten Daten dargestellt werden. Der nächste Schritt bestünde in der Definition einer aktualisierbaren Ansicht (updateable view), um der Anwenderin die Möglichkeit zu geben, neue/zusätzliche Daten einzugeben sowie vorhandene Daten ggf. zu aktualisieren/korrigieren.


  7. Die Verarbeitung der Daten

    Alle Zugriffe auf die Datenbestände finden ausschließlich über Ansichten (Views) statt. Auf diese Wege kommt die Benutzerin nur mit jenen Daten in Berührung, die für sie bestimmt sind, während die internen Daten(-Felder) verborgen bleiben.

    1. Das Einfügen der Daten

       

      1. Einfügen von Beispieldaten

        Mithilfe der oben erwähnten SQL-Skripte wurden bereits erste "Spiel-Daten" in die Tabellen eingefügt. Zunächst wurden die "unabhängigen" Tabellen erzeugt, dann Schritt für Schritt die Master- und Detail-Tabellen.

        Damit besitzen wir nicht nur eine Tabellen-Struktur, sondern auch reale (obgleich fiktive) Datensätze.

      2. Einfügen benutzerdefinierter Daten

        (... ToDo ...)

    2. Verändern von Daten

      (... ToDo ...)

    3. Löschen von Daten

      (... ToDo ...)

    4. Ausgeben/Suchen von Daten

      Hier ein paar beispielhafte Abfragen:

      1. Verteilung der Dokumente auf Sprachen.

        Eine erste Abfrage ermittelt die Verteilung der gegenwärtig erfaßten Dokumente auf die verschiedenen Sprachen.

          Sprache                           Dok-Anzahl
          --------------------------------- ----------
          Afghanisch (= Paschtu)               1
          Afrikaans                            1
          Aimara                               2
          Amharisch                            1
          Arabisch                             1
          Armenisch                            1
          Aserbaidschanisch                    1
          Assamesisch                          1
          Bambara                              1
          Baskisch                             2
          Bengalisch                           1
          Bhutanisch                           1
          Biharisch                            1
          Birmanisch                           1
          Bretonisch                           1
          Bulgarisch                           1
          Chinesisch                           2
        
          17 Zeilen ausgewählt.
        
      2. Verteilung der Dokumente pro Typ

        Durch eine ähnliche Abfrage kann die Verteilung der Dokumente auf die verschiedenen Typen ermittelt werden:

          Dok-Typ                    Dok-Anzahl
          -------------------------- ----------
          Bücher                        6
          CD (audio)                    3
          CD (data)                     1
          Zeitschrift                   5
          Zeitung                       5
        

  8. Zusammenfassung und Ausblick

    Dies ganze Projekt ist "Work In Progress". Mit anderen Worten: Es ist längst nicht "fertig". Insbesondere die Implementierung der Benutzer-Schnittstelle ist gegenwärtig nicht existent.