ISSN 1436-056X CLUE-Arbeitsberihte Nummer 7 CLUE Tehnial Reports Number 7 Wolfgang Fisher WURM - Eine Datenbank fu r die linguistishen Strukturen von JLAG Friedrih-Alexander-Universit at Erlangen-N urnberg CLUE Institut f ur Germanistik Abteilung f ur Computerlinguistik Prof. Dr. Roland Hausser, Ph. D. Fisher, Wolfgang: WURM - Eine Datenbank fur die linguistishen Strukturen von JLAG / Wolfgang Fisher - 1. Au. - Erlangen: Abt. f. Computerlinguistik (CLUE), Friedrih-Alexander Universitat Erlangen-Nurnberg, 2004 [CLUE-Arbeitsberihte/CLUE Tehnial Reports, Heft 7; Hrsg. v. Susanne Shorner℄ ISSN 1436-056X Copyright Wolfgang Fisher. First published 2004 Abteilung fur Computerlinguistik (CLUE) Bismarkstrae 12 91054 Erlangen Bundesrepublik Deutshland Gesetzt mit LATEX in 11 pt Times. Printed in Germany. Vorwort des Herausgebers Im vorliegenden Band der Reihe CLUE-Arbeitsberichte/CLUE Technical Reports der Abteilung Computerlinguistik der Friedrich-Alexander Universität Erlangen wird erneut eine Arbeit aus dem Themenbereich Computerlinguistik allen Interessierten zugänglich gemacht. Die zugrunde liegende Studienarbeit von Wolfgang Fischer wurde 2002 am Lehrstuhl für Informatik der FAU angenommen. Dank gilt dem Autor, der die Quelltexte zur Verfügung stellte und Prof. Dr. Roland Hausser für die finanziellen Mittel für den Druck. Über den Autor Wolfgang Fischer wurde 1979 in Nürnberg geboren. Nach seinem Abitur begann er im Wintersemester 1999/2000 sein Informatikstudium an der FAU. Im Rahmen seines Nebenfaches Linguistische Informatik verfasste er im WS 03/04 die vorliegende Studienarbeit. Sein Studium wird er Anfang 2005 abschließen. iii iv Inhaltsverzeichnis 1 Einleitung 1 2 Datenbankentwurf 3 3 Anforderungsanalyse 5 4 5 3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Anforderungen bezüglich der Daten . . . . . . . . . . . . . . . 6 3.2.1 Proplets . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 Intrapropositionale Beziehungen . . . . . . . . . . . . . 6 3.2.3 Extrapropositionale Beziehungen . . . . . . . . . . . . . 6 3.3 Die funktionalen Anforderungen . . . . . . . . . . . . . . . . . 7 3.4 Darstellung in JLAG . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Die Datenbankschnittstelle DBIF . . . . . . . . . . . . . . . . 10 3.5.1 Einfügeoperationen . . . . . . . . . . . . . . . . . . . . 10 3.5.2 Abfrageoperationen . . . . . . . . . . . . . . . . . . . . 10 3.5.3 Updateoperationen . . . . . . . . . . . . . . . . . . . . 11 3.5.4 Löschoperationen . . . . . . . . . . . . . . . . . . . . . 11 Konzeptioneller Entwurf 13 4.1 Entity-Relationship-Diagramme . . . . . . . . . . . . . . . . . 13 4.2 Die ER-Modellierung der Wortbank . . . . . . . . . . . . . . . 18 4.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Die Entitätstypen . . . . . . . . . . . . . . . . . . . . . 18 4.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 21 Logischer Entwurf 5.1 5.2 Das relationale Modell 23 . . . . . . . . . . . . . . . . . . . . . . 23 5.1.1 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1.2 Die relationale Algebra . . . . . . . . . . . . . . . . . . 24 Mapping des Entity-Relationship-Diagramm . . . . . . . . . . 29 5.2.1 Abbilden der Entitätstypen . . . . . . . . . . . . . . . . 29 5.2.2 Abbilden der Relationshiptypen . . . . . . . . . . . . . 29 5.2.3 Abbilden der mehrwertigen Attribute . . . . . . . . . . 31 v 5.3 5.4 6 7 5.2.4 Das resultierende Relationenschema . . . . . . . . . . . 31 5.2.5 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Anfragen auf den Relationen . . . . . . . . . . . . . . . . . . . 37 5.3.1 Behandlung der Spezialisierungshierarchie . . . . . . . 37 5.3.2 Das Attribut trc . . . . . . . . . . . . . . . . . . . . . . 38 5.3.3 Rekonstruktion der restlichen Attribute . . . . . . . . . 38 5.3.4 Ermitteln spezieller Proplets . . . . . . . . . . . . . . . 40 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . 41 Physischer Entwurf 6.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2.1 Operatoren der DDL . . . . . . . . . . . . . . . . . . . 44 6.2.2 Implementierung der WURM-Relationen . . . . . . . . 46 6.2.3 Operatoren der DCL . . . . . . . . . . . . . . . . . . . 50 Die Rekonstruktion von Proplets mit SQL 7.1 7.2 Operatoren der DML . . . . . . . . . . . . . . . . . . . . . . . 9 vi 51 51 7.1.1 Suchanfragen . . . . . . . . . . . . . . . . . . . . . . . . 51 7.1.2 Modifikationen . . . . . . . . . . . . . . . . . . . . . . . 54 7.1.3 Löschungen . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.1.4 Einfügungen . . . . . . . . . . . . . . . . . . . . . . . . 55 Die Basisanfragen in SQL . . . . . . . . . . . . . . . . . . . . . 55 7.2.1 8 43 Suchanfragen . . . . . . . . . . . . . . . . . . . . . . . . Benutzung der Datenbank in JLAG 55 61 8.1 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.2 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.2.1 Einfügungen . . . . . . . . . . . . . . . . . . . . . . . . 61 8.2.2 Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . 62 8.2.3 Löschungen . . . . . . . . . . . . . . . . . . . . . . . . . 64 8.2.4 Modifikationen . . . . . . . . . . . . . . . . . . . . . . . 64 Zusammenfassung und Ausblick 65 Einleitung 1 Die Modellierung von natürlichsprachlicher Kommunikation in Computern ist die große Aufgabe der Computerlinguistik. Dies bedeutet die Erschaffung von kognitiven Agenten, die auf der Basis einer theoretisch fundierten Funktionsmechanik frei mit Menschen in Kontakt treten können. In der Geschichte der Linguistik finden sich mit Strukturalismus, Behaviourismus und Nativismus Beispiele für Sprachtheorien1. Doch all diese Modelle berücksichtigen die Mechanik der natürlichen Sprache nicht, sondern kümmern sich nur um andere Teilbereiche. SLIM versucht, diese Lücke zu schließen; dieses Akronym steht für Surface ” compositional Linear Internal Matching“. Dieses System chararkterisiert sich folgendermaßen: Die Verarbeitung von Sprache wird funktional als Abgleich ( Matching“) von wörtlicher Sprachbedeutung und Verwendungskontext an” gesehen. Dieser Abgleich geschieht streng oberflächenkompositional ( Surface ” compositional“) und zeitlinear ( Linear“) als kognitiver Prozess innerhalb des ” Sprecher/Hörers ( Internal“). Ein stark vereinfachtes Modell zeigt folgende Ab” bildung. Abbildung 1.1: Vereinfachtes Sprachmodell von SLIM Zeichenerkennung Zeichensynthese Sprachkomponente Pragmatik Kontextkomponente Für den Nicht-Linguisten lässt sich der Kontext am besten als die Umwelt eines bestimmten Agenten zu einem bestimmten Zeitpunkt beschreiben. Sprache dient dazu, Objekte des Kontexts über Zeichen zu referenzieren. Hinsichtlich der Funktionsweise der Referenz lassen sich dabei die drei Typen Symbol, Index und Name unterscheiden; zum Beispiel kann der Verweis auf realweltliche Entitäten über Nominalphrasen (Symbole), Pronomina (Indexe) oder eben auch Namen geschehen. Genauso lassen sich die Bestandteile sprachlicher Äußerungen aber auch hinsichtlich der Hauptwortarten (Part Of Speech) unterscheiden: Dies sind Substantive, Verben und Adjektive. Da diese Differenzierung jedoch vollkommen unabhängig von der der Zeichentypen besteht, lassen sich diesen Wortarten auch Zeichentypen zuordnen. Die gerade beschriebenen Elemente natürlicher Sprache lassen sich auf ihre Grundform zurückführen, die als ihr Konzept bezeichnet wird. Wenn ein Agent 1 Darüberhinaus existieren natürlich noch viele weitere Systeme. 1 Abbildung 1.2: Zeichenkategorisierung Symbol Index Name Nomen Hund dieser Fido Adjektiv schwarz hier - Verb sehen - nun sprachliche Äußerungen analysiert, erzeugt er Mengen von Instanzen solcher Konzepte, die jeweils mit bestimmten Zeichentypen korrespondieren; diese Mengen von in Beziehung zueinander stehenden Elementen werden als kontextuelle Propositionen bezeichnet, da sie von der Ebene der Sprache auf die des Kontextes abstrahieren. Weiterhin lassen sich absolute und episodische Propositionen unterscheiden: Episodisch sind solche, die sozusagen Beobachtungen darstellen, wohingegen absolute allgemeingültige Feststellungen treffen und somit als Basis für Inferenzen dienen. Beispielsweise stellt der Satz Der Mann liest das Buch schnell.“ eine episo” dische Proposition dar, deren vier Bestandteile auf den Konzepten Mann“, ” lesen“, Buch“ und schnell“ beruhen. ” ” ” Jedoch müssen die aus der Analyse resultierenden Konzepte hinsichtlich ihrer syntaktischen Bedeutung unterschieden werden: Verben entsprechen auf logischer Ebene Funktoren und Substantive deren Argumente. Adjektive sind den Modifikatoren zuzuordnen. Um dem kognitiven Agenten Sprachproduktion und Inferenzbildung zu ermöglichen, muss ihm ein Gedächtnis gegeben werden. Diese Wortbank genannte Datenbank muss die Propositionen aufnehmen und jederzeit zur Verfügung stellen können. Mit Database Semantics“ hat Professor Hausser eine Umsetzung von SLIM ” vorgestellt. Die einzelnen Elemente der Propositionen werden als Merkmalstruktur modelliert und Proplet genannt. Sämtliche relevanten Informationen werden in ihnen codiert. Die sprachliche Komponente des in Abbildung 1.1 gezeigten Modells wird durch eine LAG realisiert. LAG steht für Links-Assoziative Grammatik“; dieser Na” me weist auf ihre zeitlineare, somit sozusagen links beginnende Vorgehensweise hin. Im Vergleich zu anderen Formalismen wie der Phrasen-StrukturGrammatik bietet sie gerade im Bereich der natürlichen Sprache einige Vorteile: Sie beruht auf dem Prinzip möglicher Fortsetzungen und bietet dadurch eine niedrigere Komplexität. Mit JLAG existiert eine Implementierung der Database Semantics von Arkadius Kycia. Die Aufgabe der vorliegenden Arbeit besteht darin, eine Wortbank auf Basis eines relationalen Datenbanksystems für JLAG zu realisieren, so dass eine dauerhafte Speicherung und Wiederverwendbarkeit gewährleistet werden kann. Dies beinhaltet einerseits den Entwurf eines Datenbankschemas, das den darzustellenden Daten gerecht wird, andererseits die Bereitstellung von Funktionen, mit denen auf diese Daten zugegriffen werden kann. Die dazu nötigen Anfragen werden im Rahmen von Methoden eines vorhandenen Java-Interfaces implementiert. 2 2 Datenbankentwurf Wie bei jeder Software bedarf es auch bei Datenbanken eines sauberen Entwicklungsprozesses, um letzten Endes ein gut funktionierendes und allen Anforderungen genügendes Produkt zu erhalten. Beim klassichen Ansatz werden hierzu folgende Phasen durchlaufen. Abbildung 2.1: Der DB-Entwurfsprozess Welt Anforderungsanalyse DB-Anforderungen Konzeptioneller Entwurf Konzeptionelles Schema Logischer Entwurf Logisches Schema Physisches Entwurf Internes Schema Zuerst werden die Anforderungen, die von den zukünftigen Benutzern an die Datenbank gestellt werden, genau untersucht, gesammelt und dokumen- tiert. Hier ist besondere Sorgfalt vonnöten, da der gesamte weitere Entwurfsprozess auf den Ergebnissen dieser Analyse beruht. Als nächstes wird die Gesamtheit der gefundenen Anforderungen in ein HighLevel-Datenmodell wie z.B. das Entity-Relationship-Diagramm oder UML abgebildet. Somit wird durch die Beschreibung noch nicht festgelegt, welches Datenmodell letztendlich in der Implementierung zum Einsatz kommt. Das Resultat dieses Entwicklungsschrittes, das sogenannte konzeptionelle Schema, sollte eine einfache Verständigung mit dem oft fachfremden Auftraggeber ermöglichen und als Basis für einen iterativen Verfeinerungsprozess dienen. Diese Phase wird als konzeptionelles Design bezeichnet. Anschließend wird im logischen Design die Entscheidung für ein bestimmtes Datenmodell getroffen, das heißt, ob z.B. ein relationales, hierarchisches oder objektorientiertes DBS verwendet wird. In dieses Modell wird das konzeptionelle Schema überführt. Das Ergebnis wird als das logisches Schema bezeichnet. Der letzte Schritt des Datenbankentwurfs ist das physische Design. Hier wer3 den die eigentlichen Speicherungsstrukturen spezifiziert und hinsichtlich des konkreten DBS angepasst, so dass man ein an die relevanten Anforderungen angepasstes sogenanntes internes Schema erhält. In den folgenden Kapiteln wird nach obigem Prozess eine Datenbank für linguistische Strukturen entwickelt. Zudem führen zu Anfang jeweils Unterabschnitte in die verwendeten Techniken und Darstellungsformen ein. 4 3 Anforderungsanalyse Die Anforderungsanalyse ist wohl der wichtigste Teil eines jeden SoftwareEngineering-Prozesses, da hier die Grundlage für alle weiteren Schritte gelegt wird und somit grundlegende Fehler in dieser Phase die Qualität des Ergebnisses in hohem Grade negativ beeinflussen können. Daher ist es nötig, mit großer Sorgfalt alle Anforderungen seitens der künftigen Nutzer des zu entwickelnden Systems zu ermitteln und genauestens zu dokumentieren. Dies umfasst im Falle von Datenbanken einerseits die Daten, die gespeichert werden sollen, und andererseits die funktionalen Eigenschaften, das heißt, die Art und Weise, wie auf die Daten zugegriffen werden soll. 3.1 Einführung Die beiden grundlegenden Begriffe der Database Semantics sind Proposition“ ” und Proplet“. Propositionen sind Mengen miteinander verknüpfter Proplets. ” Die lexikalische Definition als Satz trifft im Rahmen dieser linguistischen Betrachtung nicht zu; eine Proposition besitzt nämlich immer nur ein Verb, wohingegen Sätze durchaus aus mehreren bestehen können, z.B. wenn einzelne Teilsätze durch Konjunktionen verbunden sind, sei es bei- oder unterordnend. zum Beispiel besteht der Satz Moritz klettert auf den hohen Baum, weil er ” einen Vogel gesehen hat.“ aus zwei Propositionen: Die erste beinhaltet die Inhaltswörter Moritz“, klettert“, hohen“ und Baum“, die zweite er“, Vogel“ ” ” ” ” ” ” und gesehen“. Diese werden in Form von Merkmalstrukturen als Proplets dar” gestellt. Inhaltswörter sind also im Rahmen der natürlichen Sprache Nomina, Verben und Adjektive. Diese haben jedoch unterschiedliche Charakteristika: In der Logik entsprechen Verben Funktoren, die zu bestimmten Nomina in einer Argument-Beziehung stehen. Sowohl Nomina als auch Verben können Modifikatoren besitzen; diese entsprechen den Adjektiven1 . Die genannten Beziehungen zwischen den drei Inhaltsworttypen werden intrapropositional genannt, da sie Proplets innerhalb einer Proposition miteinander verbinden. Konjunktionen gehören hingegen zur Gruppe der Funktionswörter. Sie besitzen genau wie Negationen Operator-Charakteristik. Damit entsprechen sie extrapropositionalen Relationen, da sie Propositionen miteinander verknüpfen. Die Unterteilung der Proplets in 18 verschiedene für Nomina, 12 für Adjektive und 6 für Verben2 ist für diese Arbeit von untergeordneter Bedeutung: Die Unterscheidung der Zeichenarten Symbol, Index und Name ist nicht nötig, da sie sich aus den Merkmalen der einzelnen Proplets ableiten lassen. Ob ein sprachliches oder kontextuelles Proplet vorliegt, lässt sich in einem zusätzlichen 1 Gemäß des allgemeinen Charakters seiner wörtlichen Übersetzung als Hinzugeworfenes“ ” wird in der vorliegenden Arbeit Adjektiv“ als Oberbegriff für Adnominal und Adverbial ” benutzt. 2 siehe DBS’03 5 Attribut codieren. Ebenso verhält es sich mit dem episodischen beziehungsweise absoluten Charakter von Propositionen. Isolierte Proplets lassen sich ohnehin einfach aus den übrigen Daten ableiten, da sie Typ-Charaker besitzen und ihre Merkmale somit die Untermenge der notwendigen Eigenschaften der einzelnen Exemplare dieses Typs bilden. Die Aufgabe der im Rahmen dieser Arbeit zu erstellenden Datenbank ist es also, Folgen von Propositionen abzubilden. Das bedeutet genau genommen, dass einerseits die extrapropositionalen, andererseits die intrapropositionalen Beziehungen samt der beteiligten Proplets zu speichern sind. 3.2 Anforderungen bezüglich der Daten 3.2.1 Proplets Proplets bilden das Fundament der Database Semantics. Als Merkmalstrukturen repräsentieren sie die Inhaltswörter von Propositionen. Trotz ihrer oben beschriebenen unterschiedlichen Charakteristika als Funktoren, Argumente und Modifizierer besitzen die drei Typen Verb, Nomen und Adjektiv einen gemeinsamen Stamm an Merkmalen: • Eine Oberfläche: Das gesprochene Wort“ ” • Ein Konzept: Eine Art Stammform der Oberfläche • Eine oder mehrere Kategorien, die Eigenschaften für die syntaktische Kombinatorik darstellen • Eine oder mehrere semantische Werte, die jeweils zu genau einer Kategorie gehören • Einen Traversionszähler, der aufnimmt, wann und wie oft bei der Navigation durch die gespeicherten Propositionen ein bestimmtes Proplet abgefragt wurde Kategorien sind elementare Eigenschaften von Wörtern, wie zum Beispiel Kasus, Numerus und Genus. Durch sie lässt sich bei der syntaktischen Analyse Kompatibilität von einzelen Proplets feststellen. Zu den semantischen Werten gehören einerseits Merkmale, die schon in den Kategorien enthalten sind, als auch zusätzliche, wie zum Beispiel die Steigerungsebene von Adjektiven oder ob ein Nomen einen unbestimmten Artikel besitzt. Da die gesamte Information einer Proposition direkt in ihren Proplets steckt, wird zur Kennzeichnung der Zusammengehörigkeit ein weiteres Attribut zugeordnet: • Eine Propositionsnummer, die die Zugehörigkeit zu einer bestimmten Proposition signalisiert 3.2.2 Intrapropositionale Beziehungen Die Unterschiede zwischen den drei Typen Verb, Nomen und Adjektiv liegen in ihren intrapropositionalen Beziehungen: Ein Verbproplet hat als Funktor eine Relation zu einer Menge von Nomenproplets, seinen Argumenten. Andere Beziehungen innerhalb von Propositionen sind diejenigen von Modifikatoren zu ihren Modifikanden, das heißt, von Adjektiven zu Verben und Nomina. Diese Beziehungen müssen sich natürlich in der Datenbank wiederfinden. 3.2.3 Extrapropositionale Beziehungen Verschiedene Nomenproplets können zueinander in einer Identitätsbeziehung stehen: Die realweltliche Entität, die sie repräsentieren, ist die selbe.3 3 6 Dies ist natürlich auch innerhalb einer Proposition möglich. Die wichtigsten extrapropositionalen Beziehungen stellen jedoch die Verknüpfungen zu den in der Folge direkt vorangegangen und nachfolgenden Propositionen dar. Diese können sich in Konjunktionen wie und“ ausdrücken, jedoch können ” auch Propositionen ohne diese Bindeglieder verknüpft sein, sofern sie zu einem zusammenhängenden Textstück gehören. Die Identität von Nominal-Proplets untereinander stellt den dritten Typ der extrapropositionalen Verknüpfungen dar: Sie besteht, wenn zwei oder mehr Proplets sich auf das selbe Objekt der realen Welt beziehen. 3.3 Die funktionalen Anforderungen Die Datenbank, die die Proplets der oben beschriebenen Form aufnehmen soll, muss den funktionalen Rahmenbedingungen genügen, die die Basisgrammatiken der Database Semantics definieren: LA-Hear produziert auf Basis von Eingabetexten neue Proplets, die in den Datenbestand aufgenommen werden müssen. Wie der Name schon andeutet, entspricht dieser Vorgang dem menschlichen Hören: Erfahrungen werden gemacht und gespeichert. Die wichtigsten Anforderungen werden jedoch durch die Operationen von LAThink spezifiziert; hier findet die sogenannte Navigation statt. Dies bedeutet, dass der Agent autonom oder vom Benutzer gelenkt durch seine Wortbank steuert, die sozusagen seine Erinnerungen wiedergibt. Die Funktionalität, die durch die Schnittstelle bereitgestellt werden muss, umfasst: • Navigation innerhalb von Propositionen: Die Wortbank muss Mittel bereitstellen, um einfach die zu einer Proposition gehörigen Proplets ansteuern zu können. • Navigation zwischen benachbarten Propositionen: Es muss möglich sein, einen Text über Beziehungen vorwärts und rückwärts zwischen Propositionen erzählen“ zu können. ” • Direkter Zugriff auf bestimmte Konzepte: Da ein äußerer Reiz beim Agenten zum Gedanken an ein bestimmtes Konzept führen kann, muss die Datenbank die Möglichkeit bieten, effizient Proplets auszugeben, die ebendieses Konzept beinhalten. • Direkter Zugriff über Identitäten: Um Inferenzen anwenden zu können, ist es erforderlich, einfach mit Hilfe von Identitätsbeziehungen navigieren zu können • Modifikation von Traversionszählerwerten: Wenn an ein bestimmtes Proplet gedacht“ wurde, muss sein Traversionzähler bearbeitet werden, um ” dies zu dokumentieren. Die dritte Basisgrammatik, LA-Speak, bietet Sprachproduktion basierend auf den Denkprozessen von LA-Think. Sie stellt somit keine eigenen, direkten Anforderungen an die Datenbank. 3.4 Darstellung in JLAG Die aufgeführten Bedürfnisse seitens der Anwendungswelt führten in JLAG zu der im Folgenden beschriebenen Modellierung. Alle Proplets besitzen diese Attribute4 : 4 siehe auch 3.2.1 7 Attribut Bedeutung sur die zum Proplet gehörige Oberfläche cat unter Umständen mehrere mögliche Kategorien trc möglicherweise mehrere semantische Kennzeichen-Kombination Traversionszähler prn Propositionsnummer sem Typ Zeichenkette Zeichenkette, Vektor von Zeichenketten oder Vektor daraus; durch Klammmern separiert wie cat gespeichert als Zeichenkette, die aus einzelnen String-Repräsentationen der Zeitpunkte der Traversion besteht Integerwert Der Tatsache, dass immer ein sem- und cat-Wert zusammengehören, wird durch die Position der einzelnen Klammerausdrücke in den Zeichenketten Rechnung getragen; Dies bedeutet, dass im Falle von cat: (catwert1) (catwert2) sem: (semwert1) (semwert2) catwert1 und semwert1 genau wie catwert2 und semwert2 ein Paar bilden. Zu beachten ist jedoch, dass sich die Wertebereiche von sem und cat je nach Proplettyp unterscheiden. Von den in Kapitel 3.2.1 beschriebenen gemeinsamen Merkmalen fehlt noch Konzept“. Dieses wurde jedoch je nach Proplettyp unterschiedlich benannt: ” verb noun adj Konzept bei Verbproplets Konzept bei Nominalproplets Konzept bei Adjektivproplets Zeichenkette Zeichenkette Zeichenkette Eine Besonderheit stellt das Attribut wrdn“ dar; es ist keine direkt der Anwen” dungswelt entsprungene Anforderung. Vielmehr wurde es frühzeitig in Hinblick auf die Speicherung in der Datenbank eingeführt. Für jedes neue Proplet einer Proposition wird ein Zahlenwert vergeben, so dass durch Kombination von prn“ und wrdn“ eine eindeutige Indentifizierung gewährleistet ist. ” ” wrdn Wortnummer ein Integerwert, der jedes Proplet innerhalb einer Proposition eindeutig identifiziert. Die Nachbildung der intra- und extrapropositionalen Beziehungen der verschiedenen Proplettypen brachte spezielle Attribute mit sich. Verbproplets Abbildung 3.1 zeigt ein mögliches Verbproplet. Die zusätzlichen Attribute erklären sich wie folgt: 8 Abbildung 3.1: Beispiel eines JLAG-Verbproplets [ [ [ [ [ [ [ [ [ [ [ sur: verb: cat: sem: mdr: arg: ctn: ctp: prn: wrdn: trc: ] ] ] ] ] ] ] ] ] ] ] know DECL pres Julia dog 27 eat 28 be and 29 2 3 6 arg Argumentliste mdr Modifikatorenliste ctn connective to next“, also Ver” bindung zur nächsten Proposition ctp connective to previous“, Verbin” dung zur vorangehenden Proposition Vektor aus Zeichenketten aus einzelnen Nomenkonzepten Zeichenkette von einzelnen Adjektivkonzepten String-Vektor bestehend aus dem Konzept einer Konjunktion (falls vorhanden), der Nummer der folgenden Proposition (also prn) und dem Konzept des Verbs dieser Proposition Aufbau wie ctn, nur Oberfläche der Konjunktion am Ende des Vektors Die Reihenfolge der einzelnen Argumente in arg ist relevant, da sie die Kasus der einzelnen Nomina repräsentiert; so ist zum Beispiel das erste Element dieser Liste als Subjekt der jeweiligen Proposition zu interpretieren. Nomenproplets Die speziellen Attribute von Nomenproplets sind: mdr Modifikatorenliste fnc Funktor idy Identität eines Nomens Zeichenkette; analog zu Verbproplets Zeichenkette mit Konzept des Verbs der Proposition Integerwert Entsprechend zeigt Abbildung 3.2 ein Nominalproplet in JLAG. Abbildung 3.2: Beispiel eines JLAG-Nomenproplets [ [ [ [ [ [ [ [ [ [ sur: noun: cat: sem: mdr: fnc: idy: prn: wrdn: trc: dog SNP def sg M big know 27 29 3 1 4 ] ] ] ] ] ] ] ] ] ] 9 Adjektivproplets Adjektivproplets besitzen aufgrund der beschriebenen Beziehungen zu anderen Proplets weitere Attribute: modified“, also Angabe, wel” ches Proplet durch dieses Adjektiv modifiziert wird Identitätsverweis mdd idy Zeichenkette, die die Oberfläche des Modifikanden darstellt Integerwert, der natürlich nur im Falle von adnominaler Verwendung angibt, welche Identitätsnummer das zugehörige Nomen besitzt Ein Beispiel eines Adjektivproplets ist in Abbildung 3.3 dargestellt. Abbildung 3.3: Beispiel eines JLAG-Adjektivproplets [ [ [ [ [ [ [ [ [ sur: adj: cat: sem: mdd: idy: prn: wrdn: trc: big ADN stand dog 27 29 4 2 5 ] ] ] ] ] ] ] ] ] 3.5 Die Datenbankschnittstelle DBIF Die funktionalen Anforderungen, die an die Datenbank gestellt werden, werden letztendlich durch die Java-Schnittstelle DBIF beschrieben. Dieses Interface stellt die Grundlage für die Kommunikation zwischen JLAG und dem Datenbanksystem dar. Ein Teil der darin spezifizierten Methoden bringt tatsächliche Datenbankzugriffe mit sich; die Mehrheit jedoch operiert entweder auf temporär gepufferten Proplets oder ruft nur andere Methoden der Schnittstelle auf. Somit sind nur die Methoden der folgenden vier Gruppen aus Sicht der Datenbank relevant. 3.5.1 Einfügeoperationen In DBIF sind drei Methoden enthalten, die direkt Einfügungen mit sich bringen. Dies sind im Einzelnen: • add(Proplet p): Hinzufügen eines einzelnen Objekts der JLAG-Klasse Proplet • add(List pList): Hinzufügen eines Listen-Objekts, bestehend aus Proplets • add(Proplet[] pArray): Hinzufügen eines Arrays von Proplet-Objekten Die Funktion aller add-Varianten besteht somit im Einfügen neuer Proplets in die Wortbank. Alle drei lassen sich auf eine einzige zurückführen; in der Implementierung namens Wordbank von Arkadius Kycia ist die Hauptfunktionalität in der Array-Methode enthalten. Die beiden anderen rufen diese entsprechend auf. 3.5.2 Abfrageoperationen Die Datenbankschnittstelle bietet vier Methoden, die unmittelbar Suchanfragen nach sich ziehen: 10 • get(Proplet pattern): Ermitteln eines bestimmten Proplets, das durch die im übergebenen Muster beschrieben wird • getTokenLine(String concept): Ermitteln aller Proplets, die ein bestimmtes Konzept enthalten • getDBContent(): Ausgabe aller Proplets • getTypes(): Ermitteln aller in der Wortbank enthaltenen Konzepte In den ersten drei Fällen müssen neue Proplets beziehungsweise Listen aus neuen Proplets erstellt werden. Die vierte Methode, getTypes(), erzeugt eine Liste aus Strings. Dabei erfolgt die Ausgabe stets alphabetisch sortiert. Die Methode get(Proplet pattern) wird vor allem von LA-Think aufgerufen; hier werden, je nachdem, welcher Typ von Proplet gesucht wird, unterschiedliche Kombinationen von Attribut-Wert-Paaren im Muster-Parameter übergeben.5 3.5.3 Updateoperationen Die einzige Methode, die nach JLAG-Verständnis bestehende Proplets modifiziert ist • updateWith(Proplet p) Zwar lässt ihr Name eine allgemeine Verwendbarkeit vermuten, jedoch beschränkt sich ihr Funktionsumfang auf das Bearbeiten von trc. Die Methode wird also aufgerufen, wenn durch den Navigationsprozess ein Proplet traversiert wurde und somit dessen Traversionszählerwert um einen Zeitstempel verlängert“ werden muss. ” Durch das Parameter-Proplet wird sowohl die zu modifizierende Instanz identifiziert, als auch der neue Wert von trc übergeben. Beispielsweise muss bei Übergabe von [ [ [ [ [ [ [ [ [ [ [ sur: verb:know cat: DECL sem: pres mdr: arg: Julia dog ctn: 27 eat ctp: 28 be and prn: 29 wrdn: 2 trc: 3 6 ] ] ] ] ] ] ] ] ] ] ] das Proplet am einfachsten über die Kombination von prn und wrdn gefunden werden und anschließend der höchste Einzelwert aus der trc-Liste in die Wortbank eingetragen werden. 3.5.4 Löschoperationen Im Rahmen der normalen Betriebsart“ des JLAG-Systems als kognitiver Agent ” sind keine Löschungen zu beachten. Jedoch existiert mit • resetWordbank() eine Methode, mit der die gesamte Wortbank gelöscht werden können muss. Dies bedeutet nichts anderes als die Entfernung sämtlicher Proplets. Jedoch ist das selbstverständlich nur von administrativer Bedeutung. 5 siehe hierzu Kapitel 8.2.2 11 12 4 Konzeptioneller Entwurf 4.1 Entity-Relationship-Diagramme Ein wichtiger Bestandteil eines jeden Software-Entwicklungsprozesses ist die abstrakte Modellierung der vorgegebenen Anforderungen, um eine Grundlage für die Diskussion mit dem Auftraggeber und für die weitere Entwicklung zu schaffen. Dies sollte natürlich in einer leicht lesbaren und verständlichen Weise erfolgen. Hierzu gibt es eine Vielfalt von Techniken. Zwei aktuelle, wichtige Techniken bestehen in der Verwendung von UML und Entitity-RelationshipDiagrammen. Das Akronym UML steht für Unified Modelling Language. Diese graphische Sprache bietet ein weites Spektrum an Möglichkeiten, die weit über das für die Modellierung einer Datenbank Nötige hinausgehen; diese Vielfalt erschwert jedoch die intuitive Lesbarkeit. Gerade im Bereich der Datenbanken wird oft auf Entity-Relationship-Diagramme zurückgegriffen. Diese bieten eine relativ kompakte Syntax, die auch aufgrund der verwendeten Symbolik von vielen als leichter verständlich betrachtet wird. Dennoch wird ein hohes Maß an konstruktiver Mächtigkeit geboten. Daher soll die Modellierung der linguistischen Strukturen auf dieser abstrakten Ebene mit Hilfe eines ERD erfolgen. Im folgenden soll eine kurze Einführung in diese Technik gegeben werden; jedoch beschränkt sie sich weitestgehend auf die für die vorliegende Arbeit relevanten Elemente. Entity-Relationship-Diagramme bestehen grundsätzlich aus drei Bestandteilen: Entitätstypen, Attributen und Relationshiptypen. Entitätstypen repräsentieren Mengen von Entitäten, die dieselben Attribute besitzen. Entitäten wiederum sind Dinge der realen Welt, die eine physische oder konzeptionelle Existenz besitzen. Ein klassisches Beispiel für einen Entitätstypen ist Auto“; jede einzelne Entität, das heißt jede spezielle Instanz ” dieses Typs, hat die gleichen Attribute, z.B. Hersteller, Modellname, Farbe. Die Beziehung zwischen Entitätstyp und Entität ist ähnlich der zwischen Klasse und Objekt, wie man es aus der objektorientierten Programmierung kennt. In der Welt der Linguistik bekannter dürfte jedoch das korrespondierende Begriffspaar Type-Token sein. In einem ERD werden Entitätstypen als Rechtecke dargestellt; für die zugehörigen Attribute werden Ellipsen gezeichnet und diese über ungerichtete Kanten mit dem Entitätsyp verbunden. Die in der obigen Abbildung vorkommenden Attribute sind sogenannte einfache Attribute. Darüberhinaus existieren jedoch auch komplexe: Mehrwertige Attribute sind solche, bei denen der Wert bezüglich einer Entität 13 Abbildung 4.1: Der Entitätstyp Auto Auto Modellname Farbe Hersteller Abbildung 4.2: Ein mehrwertiges Attribut Person Telephon eine Menge darstellt. Ein Beispiel wäre eine Entität Person“ mit einem solchen ” mengenwertigen Attribut Telephon“; damit wird der Umstand modelliert, dass ” eine Person mehrere Telephonnumern haben kann. Im Diagramm wird dies mit einer doppelten elliptischen Umrandung gekennzeichnet. Ein weiteres komplexe Attributs ist das zusammengesetzte. Ein solches liegt vor, wenn die Informationen, die in ihm enthalten sein sollen, unterstrukturiert sind. Ein typisches Beispiel für ein zusammengesetzes Attribut ist Anschrift“, ” das aus den Bestandteilen Straße“ und Wohnort“ besteht. Folgende Abbil” ” dung zeigt die Darstellung in einem ERD: Abbildung 4.3: Ein zusammengesetztes Attribut Person Anschrift Straße Ort Obiges Beispiel erlaubt jedoch nur eine Anschrift pro Person; wenn in der Welt der Anwendungen auch mehrere Adressen zugelassen sind, kann man das zusammengesetzte Attribut auch zusätzlich als mehrwertiges kennzeichnen: Relationships sind Beziehungen zwischen Entitäten; Relationshiptypen stellen Mengen solcher gleichartiger Beziehungen dar. Diese werden in einem ERD als Rauten gezeichnet und werden via ungerichteter Kanten mit den beteiligten Entitätstypen verbunden. Jeder Relationshiptyp besitzt ein Kardinalitätsverhältnis, das ausdrückt, wie viele Entitäten des einen Typs zu wie vielen des anderen in Beziehung steht. Folglich gibt es hinsichtlich dieser Unterscheidung drei Klassen von Relationshiptypen: 1:1, 1:n und m:n. Einfache Beispiele für diese drei Typen wären Beziehungen mit den Namen ist-verheiratet“ zwischen einer Mann- und einer ” Frau-Entität (1:1), Vater-von“ zwischen einer Mann- und n Kind-Entitäten ” (1:n) und war-verheiratet“ zwischen m Mann- und n Frau-Entitäten. Die Kar” 14 Abbildung 4.4: Ein zusammengesetztes, mehrwertiges Attribut Person Anschrift Straße Ort dinalitäten werden an den verbindenden Kanten angetragen, wie folgendes Abbildung illustriert: Abbildung 4.5: Relationshiptypen 1 ist-verheiratet Mann Frau m 1 war-verheiratet 1 Vater-von n Kind n Eine weitere Unterscheidung von Relationshiptypen kann hinsichtlich der Partizipation getroffen werden: Wenn ein Entitätstyp total partizipiert, bedeutet dies, dass jeder einzelnen Entität eine oder mehrere Entitäten (je nach Kardinalität) auf der Gegenseite zugeordnet sind. Dementsprechend bedeutet partielle Partizipation, dass eine Entität nicht zwangsläufig zu einer Entität des anderen Typs in Beziehung stehen muss. Beispielsweise würde der Entitätstyp Kind im Relationshiptyp Vater-von-Kind total partizipieren, der Typ Mann aber nur partiell, da jedes Kind einen Vater haben, aber nicht jeder Mann Vater sein muss. Totale Partizipationen wird in einem ERD durch doppelte Kanten dargestellt, so dass obiges Beispiel in einer verfeinerten Form folgendermaßen aussieht: Auch Entitätstypen können Attribute besitzen; diese werden ebenso wie bei den Relationshiptypen als Ellipsen dargestellt und über ungerichtete Kanten verbunden. Die Syntax von Entity-Relationship-Diagrammen erlaubt auch die Modellierung fortgeschrittener Konzepte wie zum Beispiel Spezialisierung. Ein klassisches Beispiel einer Spezialisierungsbeziehung liegt zwischen den Entitätstypen Fahrzeug“ und LKW“/ PKW“ vor und wird folgendermaßen dargestellt. ” ” ” Eine mögliche Interpretation einer solchen Beziehung ist ist-ein“: Ein LKW ” ist ein Fahrzeug, ebenso ist ein PKW ein Fahrzeug. Spezialisierungen lassen sich dahingehend unterscheiden, wie sich die Entitäten der einzelnen, abgeleiteten Typen zueinander verhalten: Entweder disjunkt oder überlappend. Ersteres bedeutet, dass eine Entität immer nur einem spezialisierten Typ angehören kann. Im zweiten Fall sind auch mehrere Vorkommen erlaubt. Gemäß der englischen Übersetzungen disjoint“ und overlapping“ wer” ” 15 Abbildung 4.6: Relationshiptypen verfeinert 1 ist-verheiratet Mann Frau m 1 war-verheiratet 1 Vater-von n Kind n Abbildung 4.7: Spezialisierung Fahrzeug LKW PKW den die entsprechenden Spezialisierungen im Diagramm mit einem ’d’ beziehungsweise ’o’ im Kreis in der Mitte zwischen den beteiligten Entitätstypen gekennzeichnet. Außerdem lassen sich Spezialisierungen in totale und partielle Spezialisierungen unterteilen; im totalen Fall muss jede Entität eines Basistyps einem abgeleiteten Typ angehören, im partiellen Fall hingegen nicht. Die Darstellung erfolgt mit doppelten Kanten für totale und einfachen Kanten für partielle Spezialisierungen (analog zur Partizipation bei Relationshiptypen). Die folgenden Abbildung zeigt ein einfaches Beispiel einer totalen Spezialisierung mit disjunkt-Einschränkung: Abbildung 4.8: Totale, disjunkte Spezialisierung Mensch d Mann Frau In natürlicher Sprache bedeutet dies: Jeder Mensch ist entweder ein Mann oder eine Frau. Jeder“, weil die Spezialisierung total ist, und entweder... oder“ ” ” wegen der disjunkt-Einschränkung. 16 Damit ist die Beschreibung der für diese Arbeit relevanten ERD-Elemente abgeschlossen; im folgenden Kapitel wird auf dieser Basis die Miniwelt der linguistischen Strukturen modelliert. 17 4.2 Die ER-Modellierung der Wortbank 4.2.1 Einführung Die Modellierung der linguistischen Strukturen mit dem Ziel, eine vor allem redundanzfreie und effiziente Speicherung in einer Datenbank zu erreichen, bringt einige Unterschiede gegenüber der im eigentlichen JLAG-System vorliegenden Form mit sich. Die unterschiedlichen syntaktischen Eigenschaften der verschiedenen Proplets erfordern eine differenzierte Behandlung. Je nachdem, ob ein Verb-, Nominal-, Adnominal- oder Adverbialproplet dargestellt werden soll, ergeben sich andere Wertebereiche der einzelnen Attribute und unterschiedliche Beziehungen zu anderen Proplets. Zum Beispiel referenziert ein Adjektivproplet, das adverbiale Funktion besitzt, ein Verb, wohingegen eines mit adnominaler Funktion auf ein Nomen verweist. Von daher wurde in der Modellierung von vorneherein zwischen Adnominal und Adverbial unterschieden. Letztendlich resultieren also die vier Proplet-Entitätstypen Verb, Noun, Adnominal und Adverbial. Jedoch existiert eine Menge an Attributen, die allen genannten Typen gemeinsam ist. Dieser Umstand findet sich natürlich in der Modellierung im ER-Diagramm wieder. Ein weiterer Unterschied zur Darstellung in der JLAG-Implementierung besteht darin, dass Informationen nicht mehrfach gespeichert werden sollen; dort geschieht dies vor allem aus Gründen der Les- und Nachvollziehbarkeit. Da die Datenbank jedoch unter diesem Überbau verborgen bleibt, ist eine effiziente, redundanzfreie Speicherung von höchster Priorität. Effektiv bedeutet das, dass sich Attribute, wie sie in einem Proplet auf JLAG-Ebene auftauchen, nicht immer direkt im entsprechenden ERD oder im später daraus entwickelten Relationenschema widerspiegeln. Die für die Rekonstruktion eines JLAG-Proplets notwendigen Informationen besteht somit in vielen Fällen in der Benutzung der Beziehungen zu anderen Proplets. Wenn man von Attributen eines bestimmten Proplets spricht, könnte man also von drei Arten von Propletattributen sprechen: 1. im Basistyp Proplet gespeicherte 2. im jeweiligen abgeleiteten Typ (Noun, Verb, ...) gespeicherte 3. durch die Beziehungen zu anderen Proplets rekonstruierbare, also in anderen Typen gespeicherte 4.2.2 Die Entitätstypen Proplet Der Entitätstyp Proplet stellt die Gesamtheit aller Eigenschaften dar, die allen verschiedenen Proplet-Typen gemeinsam ist. Dies sind die Attribute prn“, ” wdn“, sur“ und concept“. concept“ stellt das Attribut dar, das auf JLAG” ” ” ” Ebene in den jeweiligen Proplets als verb“, noun“ beziehungsweise adj“ be” ” ” zeichnet wird. Ebenso gehört zu jedem Proplet ein Traversionszähler, der mit dem Namen trc“ bezeichnet wird. Im ERD wird der als mehrwertiges Attribut dargestellt, ” da er aus einer Menge von einzelnen Zeitmarken besteht. Alle weiteren Attribute, die ein Proplet auf der Ebene des JLAG-Systems besitzt, sind entweder nur bei bestimmten Proplettypen nicht-NULL oder haben je nach Proplettyp stark unterschiedliche Wertebereiche, so dass spezialisierte Entitätstypen eingeführt und mit den relevanten Attributen versehen werden. 18 Abbildung 4.9: Der Entitätstyp Proplet wdn prn sur concept trc Proplet Abbildung 4.10: Die Vererbungshierarchie mit Basistyp Proplet Proplet d Adnominal Adverb Noun Verb Verb Als erstes der spezialisierten Proplets“ soll Verb“ beschrieben werden; hier” ” unter werden alle Proplets zusammengefasst, die ein Verb darstellen. Wie auch die folgenden Entitätstypen hat Verb“ ein mengenwertiges Attribut namens ” semcat, das aus mehreren Komponenten besteht. Bei diesen handelt es sich um die JLAG-Attribute cat“ und sem“. ” ” Die Tatsache, dass hier ein zusammengesetztes Attribut modelliert wurde, begründet sich dadurch, dass jeweils ein cat- und ein sem-Wert korrespondieren. Dass dieses Kompositum als mengenwertig zu betrachten ist, liegt daran, dass in JLAG Proplets mit Multicats erlaubt sein sollen. Man mag sich wundern, dass semcat nicht als ein Attribut von Proplet modelliert wurde, wenn es doch allen Typen gemeinsam ist. Die Begründung liegt darin, dass sich die Wertebereiche von sem und cat in Verb, Noun, Adnominal und Adverbial deutlich voneinander unterscheiden. Verb“ besitzt zwei primitive Attribute, die im momentanen Stadium noch ” nicht benutzt werden: epi“ kennzeichnet, ob eine Proposition, die sich ja ein” deutig durch das zugehörige Verb bestimmen lässt, episodischen oder absoluten Charakter besitzt. Das Atribut lang“ gibt Auskunft darüber, ob es sich um eine Proposition auf ” Sprach- oder Kontextebene handelt. Gemäß der Anforderungen besteht eine Verknüpfung zwischen einem Verbproplet und demjenigen der nächsten Proposition, was in einem JLAG-Verbproplet durch das Attribut ctn“ dargestellt wird. Dieser Umstand ist im ERD als 1:1” Beziehung zwischen Verb-Entitäten modelliert. Die optionale Konjunktion, die in einem Verbproplet auf JLAG-Ebene mit in ctn“ untergebracht ist, wird als ” ein Attribut dieses Beziehungstyps betrachtet. Somit lässt sich auf Basis der gerade beschriebenen Modellierung das Attribut ctp“ einsparen, da die relevante Information auch ohne separate Speicherung ” ermittelbar ist. Das ERD weist zwei weitere Beziehungstypen ausgehend vom Verb-Entitäts19 Abbildung 4.11: Der Entitätstyp Verb mit seinen Relationshiptypen Adverbial argn Noun n arg 1 1 Verb 1 n 1 ctn semcat mdr lang epi sem ctnCnj cat typ auf: Der erste ist der mit arg“ betitelte; eine Verbproplet-Entität steht in ” einem Funktor-Argument-Verhältnis zu n Nounproplet-Entitäten (aber immer mindestens einem, so dass an dieser Stelle totale Partizipation vorliegt.). Da die Reihenfolge der Argumente jedoch aufgrund der verschiedenen Funktionalität der unterschiedlichen Casus innerhalb einer Proposition nicht unerheblich ist, besitzt arg“ ein Attribut argn“, das die Position eines Arguments in der ” ” Argumentliste des Verbs angibt. Der zweite Beziehungstyp heißt mdr“ und bezieht sich auf die Modifizierer ” eines Verbs - also die Adverbien, die durch den Entitätstyp Adverbial“ dar” gestellt werden. Ein Verb kann n Modifizierer besitzen, wobei hier der Fall ’0’ inbegriffen ist, so dass hier keinen totale Partizipation vorliegt. Das Attribut mdr“ in einem JLAG-Verbproplet besteht auf dieser Grundlage aus allen n ” Adverbien, die durch eine solche Beziehung an ein Verb gebunden werden. Im Folgenden werden die beiden neuen, zuletzt genannten Proplet-Entitätstypen Adverbial“ und Noun“ erläutert. ” ” Adverbial Der Entitätstyp Adverbial besitzt das schon oben beschriebene Attribut sem” cat“, das aus den Teilen sem“ und cat“ besteht und Multicats ermöglicht. ” ” Ansonsten sind die Werte aller Attribute, die ein Proplet mit adverbialer Funktionalität auf der Ebene des JLAG-Systems besitzt, entweder schon im Basistyp Proplet enthalten oder durch die Beziehung zu einer Verbentität ermittelbar. Abbildung 4.12: Der Entitätstyp Adverbial sem cat semcat Adverbial Noun Der Entitätstyp Noun“ repräsentiert die Proplets, die Nomina aufnehmen. ” Natürlich besitzt auch er das mehrwertige Attribut semcat. Nounentitäten können untereinander in einer Identitätsbeziehung stehen. Dem20 zufolge besteht ein rekursiver Relationshiptyp1 . Das Kardinalitätsverhältnis ist m:n, da jedem Proplet mehrere andere mit derselben Identität gegenüberstehen können. Die Funktor-Argument-Beziehung eines Nouns zu einem Verb, die in einem JLAG-Verbproplet durch das Attribut fnc“ repräsentiert wird, wurde schon ” bei der Beschreibung des Entitätstyps Verb behandelt. Der zweite Beziehungstyp, der ein Nomen einschließt, ist als mdr“ benannt und verbindet ein No” men mit seinen Modifizierern (d.h. mit seinen Adnominalen). Er ist analog zu demjenigen, der zwischen Verb und Adverb besteht. Abbildung 4.13: Der Entitätstyp Noun Adnominal n mdr 1 Noun semcat idy sem cat Adnominal Hinsichtlich der Modellierung im Entity-Relationship-Diagramm bestehen keine Unterschiede zwischen den Typen Adverbial und Adnominal. Abbildung 4.14: Der Entitätstyp Adnominal sem cat semcat Adnominal 4.2.3 Zusammenfassung Die gerade beschriebenen Elemente bilden zusammen das ERD in Abbildung 4.15. 1 Dies bedeutet, dass Beziehungen zwischen Instanzen ein und desselben Typs dargestellt werden. 21 wdn prn sur trc concept Proplet sem cat sem cat d semcat semcat Adnominal Adverb argn n mdr semcat sem 1 n Noun m idy arg n 1 1 semcat 1 Verb ctn cat n 1 lang cat sem ctnCnj Abbildung 4.15: Das komplette Entity-Relationship-Diagramm 22 mdr epi Logischer Entwurf 5 5.1 Das relationale Modell Neben dem hierarchischen, dem Netzwerk- und dem objektorientierten Datenmodell existiert mit dem relationalen Modell eine weitere Möglichkeit zur Darstellung des konzeptionellen Schemas. Seine Entwicklung hatte wohl den größten Einfluss auf die Geschichte der Datenbanken, so dass nach wie vor Systeme auf seiner Basis den Markt dominieren. Durch objekt-relationale Erweiterungen wurden diese in jüngster Zeit aufgewertet und werden so auch den Anforderungen der modernen Softwarewelt gerecht. Wie der Name schon vermuten lässt stellt der Begriff Relation“ den Kernpunkt ” des relationalen Modells dar, das sich intuitiv anhand dreier Gesichtspunkte1 charakterisieren lässt: • Struktureller Aspekt: Alle Daten einer Datenbank sind in Relationen gespeichert, die sich dem Benutzer als Tabellen darstellen. • Diese Tabellen unterliegen bestimmten Integritätsbestimmungen, die eingehalten werden müssen. • Alle Operatoren, die dem Benutzer zur Manipulation der Daten offenstehen, arbeiten auf Relationen und produzieren Relationen als Ergebnisse. 5.1.1 Relationen Relationen besitzen einen Namen und Attribute mit zugehörigen Domänen, d.h. Wertebereichen oder Datentypen. Diese drei Bestandteile bilden das sogenannte Schema einer Relation. Die Spalten stellen Attribute dar; ihre Anzahl wird als Grad einer Relation bezeichnet. Zeilen werden Tupel genannt. Deren Anzahl wird Kardinalität genannt. Eine Datenbank besteht aus einer Menge solcher Relationen, genauer gesagt aus einer Menge von Relationenschemata samt der zugehörigen Tupel. Formal definiert stellt eine Relation eine Untermenge des kartesischen Produktes aus einer Menge von Werten bestimmter Domänen dar: R ⊆ M1 × M2 × ... × Mn Jedes einzelne Element dieses Produkts stellt somit ein Tupel dar. Da Relationen mathematischen Mengen entsprechen, haben sie folgende Eigenschaften: 1. Keine zwei Tupel sind identisch, d.h. haben identische Attributwerte. 1 [Date’00] 23 Abbildung 5.1: Relation Attribute NAME Attr1 ... Attr2 Kardinalität Attrn Schema Tupel Grad 2. Die Reihenfolge der Attribute ist ebenso wie die der Tupel unerheblich. Ein weiterer wichtiger Gesichtspunkt ist, dass die vorkommenden Domänen stets nur primitive Datentypen darstellen, also nicht unterstrukturierte Werte wie Mengen oder Listen aufnehmen. Ein wichtiges Konzept des Modells ist der Schlüssel: Ein Schlüsselkandidat ist eine Menge von Attributen, die ein Tupel eindeutig identifiziert. Diese muss minimal sein, das heißt, es existiert keine Untermenge, die auch eindeutig Tupel bestimmt. Da es möglicherweise mehrere Kandidaten gibt, muss für jede Relation einer ausgewählt werden, der dann als Primärschlüssel bezeichnet wird. Wenn extra ein Attribut als Primärschlüssel eingeführt wird, spricht man auf englisch von einem surrogate key“. ” Über sogenannte Fremdschlüssel lassen sich Tupel auch über Relationen hinweg referenzieren. Fremdschlüssel stellen Attribute dar, deren Werte mit denen der Primärschlüssel von Tupeln der referierten Relation übereinstimmen müssen oder NULL sind. Dieser Umstand wird als referentielle Integrität bezeichnet. Ein System, das das relationale Modell implementiert, muss diese unbedingt gewährleisten. Darüber hinaus lässt das relationale Modell weitere Integritätsbestimmungen zu, die von Benutzer definiert werden können. Sie stellen Regeln aus der Anwendungswelt dar. Ihre Einhaltung muss vom Datenbanksystem gewährleistet werden. 5.1.2 Die relationale Algebra Die relationale Algebra besteht aus einer Menge von Operatoren, die auf Relationen arbeiten und wiederum Relationen hervorbringen. Sie stellt den funktionalen Teil des relationalen Modells dar. Die Operatoren sind von zweierlei Natur: Da Relationen im Prinzip Mengen sind, lassen sich auf sie einerseits die typischen Mengenoperatoren Vereinigung, Schnitt, Differenz und kartesisches Produkt anwenden. Andererseits existieren noch vier weitere, speziell für den Datenbankgebrauch entwickelten Operatoren: Die Projektion, die Selektion, der Join und die Division. Im Folgenden sollen sie jeweils kurz erläutert werden. Projektion Mit Hilfe der Projektion werden Attribute ausgewählt, das heißt, es werden Relationen auf Unterrelationen reduziert, die nur noch einen Teil der Attribute enthalten. Somit gilt also mit R2 = P ROJ[attributliste]R1 24 Grad(R2 ) ≤ Grad(R1 ) Folgendes Abbildung illustriert eine Projektion: Abbildung 5.2: Die Projektion Vorname Nachname Alter Bernd Schmidt 22 Paula Müller 24 Michael Müller 19 Nachname PROJ[Nachname] Schmidt Müller Jedoch verringert sich unter Umständen nicht nur der Grad, sondern auch die Kardinalität einer Relation, wie obiges Beispiel zeigt. Dies begründet sich darin, dass es keine zwei identischen Tupel geben darf. Dazu kann es jedoch kommen, wenn die Attributliste der Projektion keinen Schlüssel der Ausgangsrelation beinhaltet. Deshalb müssen die Tupel mit gleichen Werten auf einen einzigen reduziert werden. Selektion Dieser auch als Restriktion bezeichnete Operator dient dazu, Tupel einer Relation auszuwählen. Dazu dient eine bestimmte Auswahlbedingung. In der Resultatsrelation sind nur diejenigen Tupel enthalten die dieser Bedingung genügen. Das Ergebnis einer Selektion R2 = SEL[bedingung]R1 besitzt also möglicherweise eine geringere Kardinaltität als die Ursprungsrelation: Kardinalität(R2 ) ≤ Kardinalität(R1 ) Der Grad hingegen bleibt stets konstant. Selektionsbedingungen bestehen aus Elementareinheiten, die auch über boolesche Verknüpfungen zu komplexen Bedingungen konstruiert werden können. Einfache Bedingungen besitzen die Form Attributname V ergleichsoperator Konstante | Attributname1 V ergleichsoperator Attributname2 Eine einfache Selektion zeigt folgendes Beispiel: Abbildung 5.3: Die Selektion Vorname Nachname Bernd Schmidt Paula Müller Michael Müller Vorname SEL[Nachname=Müller] Nachname Paula Müller Michael Müller Join Die Join-Operation basiert auf der Anwendung einer Selektion auf das Ergebnis eines kartesischen Produktes. Es lässt sich somit als R3 = R1 JOIN [bedingung]R2 = SEL[bedingung](R1 × R2 ) 25 darstellen. Der Sinn eines solchen Operators besteht darin, Tupel verschiedener Relationen zu vereinigen, die in einer bestimmten Beziehung zueinander stehen. Diese Beziehung stellt sich oftmals durch einen Fremdschlüssel dar. Mit Hilfe des kartesischen Produkts allein lassen sich Tupel mehrerer Relationen wahllos kombinieren. Dies geschieht, indem jedes Tupel der einen Relation mit jedem der anderen Relation verbunden wird, das heißt, indem die Attributwerte der Tupel konkateniert werden. Der Grad des Resultats R3 = R1 (attribut1 ...attributm ) × R2 (attribut1 ...attributn ) ergibt sich also als Grad(R3 ) = Grad(R1 ) + Grad(R2 ) = m + n Die Kardinalität lässt sich durch Kardinalität(R3 ) = Kardinalität(R1 ) ∗ Kardinalität(R2 ) = m ∗ n berechnen. Die folgende Abbildung illustriert die Anwendung des kartesischen Produkts: Abbildung 5.4: Das kartesische Produkt Vorname Nachname Alter Bernd Schmidt 22 Paula Müller 24 Müller Michael Name Telephon Schmidt 09131-112 Müller 0911-110 19 X Vorname Nachname Alter Name Telephon Bernd Schmidt 22 Schmidt 09131-112 Bernd Schmidt 22 Müller 0911-110 Paula Müller 24 Schmidt 09131-112 Paula Müller 24 Müller 0911-110 Michael Müller 19 Schmidt 09131-112 Michael Müller 19 Müller 0911-110 Auf den ersten Blick erscheint das kartesische Produkt weitgehend nutzlos, da Tupel ohne Zusammenhang kombiniert werden. Seine Bedeutung für Datenbanken ergibt sich erst im Kontext des Join-Operators; durch die zugehörige Restriktion werden letztendlich sinnvolle“ Tupel gebildet: ” Abbildung 5.5: Der Join Vorname Nachname Alter Bernd Schmidt 22 Paula Müller 24 Michael Müller Name Telephon Schmidt 09131-112 Müller 0911-110 19 JOIN[Nachname=Name] Vorname Nachname Alter Telephon Bernd Schmidt 22 09131-112 Paula Müller 24 0911-110 Michael Müller 19 0911-110 Es existieren mehrere Untervarianten des Operators: Im Falle des allgemeinen Join finden sich die Vergleichsattribute beider Seiten in der Ergebnisrelation 26 wieder. Der Subtyp Equi-Join lässt als Vergleichsoperation nur den Test auf Gleichheit zu. Darauf aufbauend bietet der sogenannte Natural-Join zusätzlich die Elimination der doppelten Join-Attribute, die im Falle einer Gleichheit entstehen. Dieser letzte Typ ist auch der meistbenutzte und wurde in den oben genannten Beispielen benutzt. Im Kontext der zu entwickelnden Datenbank ist eine zusätzliche Unterart wichtig: Der sogenannte Outer-Join. Mit ihm lassen sich auch Tupel, die keinen Verbundpartner finden, in die Ergebnisrelation aufnehmen; da diese dann aber natürlich nicht für alle Attribute Werte besitzen, werden diese mit null“ auf” gefüllt. Der Outer-Join existiert in drei Varianten: Der Left-Outer-Join nimmt nur partnerlose Tupel der links vom Operator stehenden Relation zusätzlich auf, der Right-Outer-Join nur die der rechten. Mit Full-Outer-Joins werden beide Seiten berücksichtigt, so dass kein Tupel verloren geht“. ” Diese Join-Variante ist vor allem dann nützlich, wenn bestimmte Tupel zu anderen in einer optionalen Teil-Ganzes-Beziehung stehen. Basierend auf den oben benutzten Relationen könnte man sich zum Beispiel eine Anfrage vorstellen, die alle Personen und - falls vorhanden - ihre Telephonnummern ausgeben soll. Mit einem konventionellen Join würden die Tupel von Personen ohne Telephonanschluss2 nicht in der Ergebnisrelation erscheinen. Abbildung 5.6: Der Left-Outer-Join Vorname Nachname Alter Bernd Schmidt 22 Paula Müller 24 Manfred Vogel 18 Name Telephon Schmidt 09131-112 Müller 0911-110 LEFT OUTER JOIN [Nachname=Name] Vorname Nachname Alter Telephon Bernd Schmidt 22 09131-112 Paula Müller 24 0911-110 Manfred Vogel 18 NULL Division Die Division ist der vierte, speziell für Datenbanken entwickelte Operator. Er ist auf zwei Relationen definiert: Die eine nennt sich Dividend, die andere Divisor; letztere stellt in ihrem Aufbau einen Teil des Dividenden dar. Das Ergebnis einer Division ist die Menge der Dividendentupel, die in den relevanten Attributen mit einem Tupel des Divisors übereinstimmen, abzüglich eben dieser Attribute. Oder anders ausgedrückt: Mit R1 als Dividend und R2 als Divisor ist R3 (a1 ...an ) = R1 (a1 ...an , b1 ...bm )DIV R2 (b1 ...bm ) das Ergebnis der Division der beiden. Erweiterungen Zusätzlich zu den beschriebenen Operatoren erweist sich ein weiterer aus Gründen der Übersichtlichkeit und Verständlichkeit als nützlich: Die Umbenennung. Daher wird sie unter der Bezeichnung REN“ (für rename“) folgendermaßen ein” ” geführt: Mit der Ausgangsrelation R1 (a1 , a2 , a3 ) 2 Oder ohne bekannte Nummer. Hier zeigt sich die Möglickeit der mehrfachen Interpretation von null-Werten. 27 ergibt sich durch REN [R2 (b1 , b2 , b3 )]R1 eine neue Relation R2 (b1 , b2 , b3 ), die mit R1 bis auf die Namen von Relation und Attributen identisch ist; das heißt a1 entspricht nun b1 etc. . Es müssen aber nicht beide Teile neu festgelegt werden. Da die Mengenoperationen als bekannt vorausgesetzt werden dürfen, ist an dieser Stelle die Einführung in das relationale Modell abgeschlossen. Das nächste Kapitel behandelt nun die Umsetzung der in den vorherigen Kapiteln beschriebenen Miniwelt. 28 5.2 Mapping des Entity-Relationship-Diagramm Um das in den vorangegangenen Kapiteln beschriebenen Modell der linguistischen Strukturen in einem konkreten relationalen Datenbanksystem verwenden zu können, muss ein entsprechendes Relationenschema entwickelt werden. Dieser Vorgang wird auch als Mapping bezeichnet. Dabei werden schrittweise die Konstrukte des ERD auf Relationen abgebildet und letztere erweitert. Das resultierende Schema ist jedoch nicht eindeutig, da in vielen Punkten verschiedene Möglichkeiten der Umsetzung existieren. Daher hat der Designer gewisse Freiheitsgrade, was eine Optimierung der Datenbank hinsichtlich der Anwendungswelt ermöglicht. Im Folgenden soll beschrieben werden, wie das oben entwickelte Entity-Relationship-Diagramm auf Relationen abgebildet wurde. Es werden deshalb nur die für diese spezielle Umgebung nötigen MappingSchritte dargestellt. 5.2.1 Abbilden der Entitätstypen Als erstes wird für jeden vorkommenden Entitätstypen direkt jeweils eine Relation geschaffen, die alle einfachen Attribute enthält. Das Mapping von Proplet3 führt zum Beispiel zur folgenden Relation: Abbildung 5.7: Die Relation proplet proplet ( prn, wdn, sur, concept ) Primärschlüssel: (prn,wdn) Gleichzeitig wird ein Primärschlüssel gewählt, der ein Tupel der jeweiligen Relation eindeutig identifiziert. Im Falle von proplet ist dieser aus den Attributen prn und wdn zusammengesetzt. Sämtliche anderen Entitätstypen sind von Proplet abgeleitet; dieser Umstand wird dadurch abgebildet, dass jeder dieser Typen den Primärschlüssel der Relation proplet als Fremdschlüssel als weiteres Attribut (bzw. als weitere Attribute, wenn der Schlüssel zusammengesetzt ist) erhält. Es entstehen also folgende Relationen: Abbildung 5.8: Die Relationen der spezialisierten Typen adnominal ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet noun ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet verb ( prn, wdn, lang, epi ) Primärschlüssel: (prn) Fremdschlüssel: (prn,wdn) referenziert proplet adverb ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet Die beiden Relationen noun, adnominal und adverb besitzen in diesem Stadium des Mappings noch keine weiteren, speziellen Attribute; dies ändert sich jedoch im weiteren Verlauf. Eine Besonderheit stellt die Relation verb dar: Hier wird nicht wie in den anderen angeführten Fällen ein aus prn und wdn zusammengesetzter Primärschlüssel benötigt. Das Attribut prn allein genügt, da eine Proposition stets nur ein Verb beinhalten kann. 3 siehe 4.9 29 5.2.2 Abbilden der Relationshiptypen Die nächste Stufe des Mapping-Prozesses ist die Abbildung der Relationshiptypen. Zuerst werden die 1:1-Beziehungstypen betrachtet. Im vorliegenden Diagramm liegt nur ein einziger vor: Der rekursive zwischen zwei Verb-Entitäten namens ctn. Die zweckmäßige Umsetzung besteht darin, die Relation verb um ein Attribut zu erweitern, das den Primärschlüssel des über ctn referenzierten Tupels als Fremdschlüssel aufnimmt. Der Relationshiptyp ctn besitzt jedoch ein eigenes Attribut namens ctncnj, das natürlich auch im relationalen Schema berücksichtigt werden muss. Dies geschieht, indem man dieses Attribut ebenfalls der Relation verb hinzufügt: Abbildung 5.9: Die Relation verb mit Fremdschlüsselattribut ctn verb ( prn, wdn, lang, epi, ctn, ctncnj ) Primärschlüssel: (prn) Fremdschlüssel: (ctn) referenziert verb Nun werden die 1:n-Relationshiptypen umgesetzt; die lehrbuchmäßige Lösung sieht vor, die Relation auf der n-Seite der Beziehungsmenge um ein Fremdschlüsselattribut zu erweitern, das sich auf die 1-Seite bezieht. So wurde prinzipiell auch bei arg, mdr (adverb-verb) und mdr (adnominal-noun) verfahren; jedoch ist hier eine Besonderheit von Bedeutung: im Falle der Beziehungstypen arg und mdr (adverb-verb) wird die Relation verb referenziert, die den Primärschlüssel prn besitzt. Die Information, die ein zusätzliches Fremdschlüsselattribut in noun beziehungsweise adverb aufnehmen würde, ist jedoch jeweils schon im eigenen Attribut prn enthalten. Denn die beschriebenen Beziehungen bestehen stets nur zwischen Proplets einer Proposition, so dass der Wert von prn in den beteiligten Tupeln gleich sein muss. Somit kann auf die Erweiterung durch zusätzliche Fremdschlüsselattribute verzichtet werden. Ähnlich verhält es sich im Falle des Relationshiptyps mdr, der Tupel aus adnominal und noun verbindet: Auch hier ist prn schon enthalten. Jedoch muss der Relation adnominal (n-Seite) ein Attribut hinzugefügt werden, da der Primärschlüssel von noun nicht nur aus prn, sondern zusätzlich aus wdn besteht. Dieses neue Attribut wird mit mddnoun bezeichnet, was für modified ” noun“ steht. Wie schon ctn ist auch dem Beziehungstyp arg ein Attribut zugeordnet, das in analoger Weise der Relation, die den Fremdschlüssel aufnimmt (also noun), hinzugefügt wird. Abbildung 5.10: Die Relationen nach dem Mapping der Relationshiptypen adnominal ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet Fremdschlüssel: (prn, mddnoun) referenziert noun noun ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet Fremdschlüssel: (prn) referenziert verb adverbial ( prn, wdn ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet Fremdschlüssel: (prn) referenziert verb Der einzige Beziehungstyp mit dem Kardinalitätsverhältnis m:n im Diagramm ist derjenige namens idy: Er bildet die Identität zwischen Nomina ab und verbindet somit noun-Tupel mit untereinander. Normalerweise führt man zur Abbildung von m:n-Relationshiptypen Kardinalitäten eine zusätzliche Relation ein, die die Primärschlüssel der an diesem Beziehungstyp beteiligten Relationen 30 als Fremdschlüsselattribute aufnimmt. Da idy jedoch rekursiv noun-Entitäten verknüpft, empfiehlt sich eine andere Lösung, durch die der hohe Wartungs- und Abfrageaufwand, den die Variante mit Zusatzrelation mit sich bringen würde, vermieden werden kann: Die Relation noun wird um ein Attribut namens idy erweitert, das eine Identitätsnummer darstellt. Durch Restriktion in einer Anfrage kann dann leicht ermittelt werden, welche Nouns dieselbe realweltliche Entität darstellen. Das Mapping der Beziehungstypen führt also zu den modifizierten Relationen in Abbildung 5.10. 5.2.3 Abbilden der mehrwertigen Attribute Die letzten noch nicht gemappten Elemente des ERD sind die mehrwertigen Attribute. Eines davon ist trc, das zum Entitätstyp Proplet gehört. Zu seiner Umsetzung wird eine zusätzliche Relation angelegt, die einzelne Traversionszählerwerte (d.h. Zeitstempel) aufnimmt und per Fremdschlüsselbeziehung das zugehörige Tupel in proplet referenziert: Abbildung 5.11: Die Relation trc trc ( prn, wdn, timestamp ) Primärschlüssel: (*) Fremdschlüssel: (prn, wdn) referenziert proplet Dies entspricht der klassischen Abbildung von mehrwertigen Attributen und ist hier vollkommen angemessen. Anders wurden hingegen in den restlichen Fällen verfahren. Die entsprechenden Attribute sind jeweils als semcat“ benannt und ” unterscheiden sich auf ERD-Ebene nur durch ihre Entitätstyp-Zugehörigkeit. Dementsprechend erfolgt ihr Mapping analog. Semcat setzt sich aus den sem und cat zusammen. Bei näherer Betrachtung der Werte dieser beiden Attribute im JLAG-System stellt man fest, dass ihre Werte komplexe Zeichenketten darstellen können. Insofern ist eine 1:1-Übernahme in das Relationenmodell nicht empfehlenswert. Eine Lösung besteht darin, die Werte als Listen von Elementarbausteinen zu betrachten. Dies soll am Beispiel von noun erläutert werden: Zwei Relationen nounsem und nouncat werden eingeführt und mit folgenden Attributen versehen: Einem Fremdschlüssel, der das zugehörige Tupel in noun referenziert, einem primitiven sem- bzw. catWert und einer Positionsangabe, die kennzeichnet, an welcher Stelle der Liste der Wert vorkommt. Demnach ergibt sich folgendes Schema für nounsem: Abbildung 5.12: Die Relation nounsem provisorisch nounsem ( prn, wdn, semvalue, semn ) Primärschlüssel: (*) Fremdschlüssel: (prn, wdn) referenziert noun semvalue“ ist der Name des Attibuts für die einfachen sem-Werte und semn“ ” ” nimmt die Positionsangabe auf. Jedoch sind die resultierenden Relationen noch nicht auf den mehrwertigen Charakter von semcat abgestimmt. Dieses Problem wird gelöst, indem man ein weiteres Attribut einführt, das die Zugehörigkeit zu einem bestimmten semcatPaar kennzeichnet. Hier wäre auch eine alternative, mehrstufige4 Abbildung möglich, die zwar dem Diagramm näher stehen würde, aber keine Vorteile, sonder sogar Nachteile hinsichtlich der Performanz mit sich bringt. Somit ergibt sich das in 5.13 dargestellte Bild. Dieses Schema wird analog für die anderen Proplet-Untertypen angewendet. Wiederum ist natürlich im Falle der Relation verb die Besonderheit zu beachten, dass deren Primärschlüssel nur aus prn besteht. 4 Die gewählte Variante schafft die Zwischenstufe semcat“ ab. ” 31 Abbildung 5.13: Die Relationen nounsem und nouncat nounsem ( prn, wdn, semcatn, semvalue, semn ) Primärschlüssel: (*) Fremdschlüssel: (prn, wdn) referenziert noun nouncat ( prn, wdn, semcatn, catvalue, catn ) Primärschlüssel: (*) Fremdschlüssel: (prn, wdn) referenziert noun 5.2.4 Das resultierende Relationenschema Folgende Zusammenfassung stellt das komplette Relationenschema inklusive einer kurzen Beschreibung der Attribute und deren Wertebereiche dar, sofern sie nicht schon definiert sind. 32 proplet ( prn, wdn, sur, concept ) Primärschlüssel: (prn,wdn) Attribute: prn: wdn: sur: concept: trc ( prn, wdn, timestamp ) Primärschlüssel: (*) Fremdschlüssel: (prn, wdn) referenziert proplet Attribute: timestamp: adnominal Zeitmarke, zu der ein Proplet zuletzt traversiert wurde Ganzzahlwert ( prn, wdn, mddnoun ) Primärschlüssel: (prn,wdn) Fremdschlüssel: (prn,wdn) referenziert proplet Fremdschlüssel: (prn, mddnoun) referenziert noun Attribute: mddnoun: adnsem Nummer der Proposition, der das Proplet angehört; Ganzzahlwert Laufende Nummer des Wortes innerhalb der Proposition; Kleiner Ganzzahlwert Oberfläche der Wortform; Zeichenkette Der Wortform zugrundeliegendes Konzept; Zeichenkette Die Nummer des modifizierten Wortes in der Proposition Ganzzahlwert (wdn entsprechend, da Fremdschlüssel) ( prn, wdn, semcatn, semvalue, semn ) Primärschlüssel: ( prn, wdn, semcatn, semn ) Fremdschlüssel: ( prn, wdn ) referenziert adnominal Attribute: semcatN: semvalue: semN: Sem/cat-Nummer, Kennzeichnung eines Wertepaars zur reihenfolgetreuen Darstellung in den jeweiligen Listen; Kleiner Ganzzahlwert Elementarer sem-Wert, aus dem der eigentliche Wert rekonstruiert wird. (Semantische Eigenschaften eines Proplets) Zeichenkette aus { stand“, comp“, sup“} ” ” ” Position des elementaren sem-Wertes innerhalb eines sem-Strings; Kleiner Ganzzahlwert 33 adncat ( prn, wdn, semcatn, catvalue, catn ) Primärschlüssel: ( prn, wdn, semcatn, catn ) Fremdschlüssel: ( prn, wdn ) referenziert adnominal Attribute: catvalue: catN: noun ( prn, wdn, idy, argn ) Primärschlüssel: ( prn, wdn ) Fremdschlüssel: ( prn, wdn ) referenziert proplet Fremdschlüssel: ( prn ) referenziert verb Attribute: idy: argn: nounsem Zeichenkette aus { NS1“, PRO2“, NS3“, NP-2“, ” ” ” ” OBQ“, SNP“, PNP“, NM“, SN“, PN“} ” ” ” ” ” ” ( prn, wdn, epi, lang, ctn, ctncnj ) Primärschlüssel: ( prn ) Fremdschlüssel: ( prn, wdn ) referenziert proplet Fremdschlüssel: ( ctn ) referenziert verb Attribute: epi: lang: ctn: ctncnj: 34 Zeichenkette aus { F“, M“, sg“, pl“, def“, in” ” ” ” ” ” def“, sel“, exh“} ” ” ( prn, wdn, semcatn, catvalue, catn ) Primärschlüssel: ( prn, wdn, semcatn, catn ) Fremdschlüssel: ( prn, wdn ) referenziert noun Attribute: catvalue: verb Zur Abbildung von Identitäten zwischen Nouns; Ganzzahlwert Nummer eines Noun in der Arg-Liste des zugehörigen Verbs; Kleiner Ganzzahlwert ( prn, wdn, semcatn, semvalue, semn ) Primärschlüssel: ( prn, wdn, semcatn, semn ) Fremdschlüssel: ( prn, wdn ) referenziert noun Attribute: semvalue: nouncat Elementarer cat-Wert, aus dem der eigentliche Wert rekonstruiert wird. (syntaktische Kategorie eines Proplets) Zeichenkette aus { ADN“} ” Position des elementaren cat-Wertes innerhalb eines cat-Strings; Kleiner Ganzzahlwert Ist die zugehörige Proposition episodisch oder absolut? Boolesch Ist die zugehörige Proposition auf Sprach- oder Kontextebene? Boolesch Verweis auf die nächste Proposition bzw. das nächste Verb-Proplet; Ganzzahlwert (prn entsprechend, da Fremdschlüssel) Konjunktion, die Proposition mit der nächsten verbindet, auch leer möglich; Zeichenkette verbsem ( prn, semcatn, semvalue, semn ) Primärschlüssel: ( prn, semcatn, semn ) Fremdschlüssel: ( prn ) referenziert verb Attribute: semvalue: verbcat Zeichenkette aus { pres“, past“, be-pres“, hv” ” ” ” pres“, do-pres“, be-past“, hv-past“, do-past“, ” ” ” ” perf“, prog“, neg“} ” ” ” ( prn, semcatn, catvalue, catn ) Primärschlüssel: ( prn, semcatn, catn ) Fremdschlüssel: ( prn ) referenziert verb Attribute: catvalue: Zeichenkette aus { DECL“, V“, N’“, N-S3´“, ” ” ” ” NS1’“, NS3’“, NS13’“, N-S13’“, A’“, D’“, ” ” ” ” ” ” SN’“, PN’“, BE’“, HV’“, DO’“ } ” ” ” ” ” adverbial ( prn, wdn ) Primärschlüssel: ( prn, wdn ) Fremdschlüssel: ( prn, wdn ) referenziert proplet Fremdschlüssel: ( prn ) referenziert verb advsem ( prn, wdn, semcatn, semvalue, semn ) Primärschlüssel: ( prn, wdn, semcatn, semn ) Fremdschlüssel: ( prn, wdn ) referenziert adverbial Attribute: semvalue: advcat Zeichenkette aus { stand“, comp“, sup“} ” ” ” ( prn, wdn, semcatn, catvalue, catn ) Primärschlüssel: ( prn, wdn, semcatn, catn ) Fremdschlüssel: ( prn, wdn ) referenziert adverbial Attribute: catvalue: Zeichenkette aus { ADV“} ” 35 5.2.5 Überblick Zur Verdeutlichung soll nun ein Überblick gegeben werden, wie die Attribute von JLAG und die der Datenbank zusammenhängen. Dabei wird zur Identifikation eine Punktnotation mit der Bedeutung relationenname.attributname benutzt. Besitzt ein JLAG-Attribut aus Gründen der Redundanzfreiheit kein entsprechendes Pendant in den Tupeln des eigentlichen Proplets und muss über Fremdschlüssel ermittelt werden, werden diese indirekt benutzten Attribute durch Klammern eingeschlossen. Um ein gewisses Maß an Übersichtlickeit zu gewährleisten, soll an dieser Stelle stets auf die explizite Nennung von Fremdschlüsselbeziehungen beziehungsweise deren Attribute verzichtet werden. 36 JLAG- Information in der DB: Attribut: Bemerkungen sur proplet.sur Momentan stets null noun verb adj proplet.concept proplet.concept proplet.concept cat ...cat.catvalue sem ...sem.semvalue mdr (proplet.concept) mdd proplet.concept arg (proplet.concept) fnc (proplet.concept) idy noun.idy prn wrdn proplet.prn proplet.wdn trc trc.timestamp cat wird in einzelne Werte zerlegt. Zur Rekonstruktion sind daher die Attribute semcatn und catn aus der gleichen Relation nötig. Diese hängt vom Typ des Proplets ab. dito, jedoch mit semcatn und semn Die Werte entsprechen Konzepten von Adnominal- bzw. Adverbial-Proplets. Das in mdd enthaltene Konzept des modifizierten Proplets lässt sich über Fremdschlüsselbeziehungen ermitteln. Die Konzepte der Argument-Proplets (Nomina) besitzen eine relevante Ordnung, die durch das noun.argn gespeichert wird. Die Werte entsprechen Konzepten von Verb-Proplets. Im Falle von Noun-Proplets direkt im zugehörigen Tupel von noun, bei Adnominal-Proplets im zugehörigen Nomen Die einzelnen Zeitmarken; die Reihenfolge kann durch eine nach den Werten aufsteigend geordnete Ausgabe erhalten werden. 5.3 Anfragen auf den Relationen Auf die definierten Relationen können nun Kombinationen von relationalen Operatoren angewendet werden, so dass sich die Informationen entsprechend der funktionalen Anforderungen extrahieren lassen. Im folgenden sollen Ausdrücke der relationalen Algebra für die einzelnen Anfragen, die seitens JLAG gestellt werden, angegeben werden. Da im beschriebenen konzeptionellen Schema ein Proplet keine Einheit wie in JLAG mehr darstellt, bedarf es einiger Schritte, um es wieder inkrementell zu rekonstruieren. Dabei gibt es mehrere Möglichkeiten: Die beiden Extreme sind der Join aller nötigen Relationen einerseits , so dass sich alle nötigen Informationen zur Rekonstruktion einer JLAG-Merkmalstruktur in einer einzigen Relation finden lassen, und die separate Abfrage auf höchster Ebene andererseits. Bei der letzten Variante muss sozusagen eine Art Join außerhalb eines Datenbanksystems durchgeführt werden. Im unten beschriebenen Vorgehen wurde eine hybride Strategie verfolgt: Sämtliche JLAG-Attribute, die sich in der Datenbank auf mehrere Tupel verteilen, das heißt, die mengenwertig sind, werden über separate Abfragen ermittelt. Betroffen sind also zum Beispiel für Proplets aller Typen trc, sem und cat. Diese Abfragen müssen dann natürlich Selektionen beinhalten, die als Bedingungen die der Joins besitzen, die sie ersetzen. Dagegen werden die Werte aller einfachen Attribute über echte“ Join-Anwendungen berechnet. ” Der Vorteil dieser Lösung besteht vor allem in einer besseren Übersichtlichkeit hinsichtlich der resultierenden Relationen; außerdem ergibt sich auch, wenn später basierend auf den entsprechenden Termen der relationalen Algebra Anfragen erstellt werden, eine leichtere Verarbeitung der Tupel. Dies ist insofern von Bedeutung, als das zu entwickelnde System Pioniercharakater besitzt und somit verständlich gehalten werden sollte. 5.3.1 Behandlung der Spezialisierungshierarchie Der wichtigste Schritt ist die Kombination der Attribute von Tupeln der Relation proplet mit denen der Relationen verb, noun, adnominal und adverbial. Somit wird die Aufspaltung zwischen Basis- und abgeleitetem Typ aufgehoben. Im Falle von verb geschieht diese Konkatenation durch folgenden Natural-Join: verbproplet = proplet JOIN [proplet.prn = verb.prn proplet.wdn = verb.wdn] AN D verb Die Resultatsrelation verbproplet besitzt also folgendes Schema: verbproplet(prn, wdn, concept, sur, epi, lang, ctn, ctncnj) Für die anderen Typen sind die Joins analog aufgebaut: nounproplet = proplet JOIN [proplet.prn = noun.prn proplet.wdn = noun.wdn] AN D noun adnominalproplet = proplet JOIN [proplet.prn = adnominal.prn proplet.wdn = adnominal.wdn] adnominal adverbialproplet = proplet JOIN [proplet.prn = adverbial.prn proplet.wdn = adverbial.wdn] AN D AN D adverbial 37 Dementsprechend ergeben sich folgende Schemata: nounproplet(prn, wdn, concept, sur, idy, argn) adnominalproplet(prn, wdn, concept, sur, mddnoun) adverbialproplet(prn, wdn, concept, sur) 5.3.2 Das Attribut trc Um den Traversionszähler eines Proplets wiederherzustellen, müssen sämtliche einzelnen Zeitstempelwerte aus der Relation trc passend zu einem bestimmten (prn,wdn)- Schlüsselwert ermittellt werden. Dies geschieht direkt auf der Basisrelation trc(prn, wdn, timestamp) mit einer Selektion der Form SEL[prn = x, wdn = y]trc. 5.3.3 Rekonstruktion der restlichen Attribute Verben In den einzelnen Tupeln der berechneten Relation verbproplet sind noch nicht alle Informationen enthalten, die sie für die Ausgabe an JLAG benötigen. Dies betrifft die Attribute ctn, ctp, mdr, sem und cat. ctn: Für die Rekonstruktion des JLAG-Attributs ctn fehlt in der Relation verbproplet nur das Konzept des Verbs der nächsten Proposition. Um dieses zu berechnen, genügt ein Join mit den Basisrelationen verbproplet und proplet; da jedoch nicht jede Proposition einen Nachfolger haben muss, ist ein Outer-Join nötig. Zuerst können jedoch noch die relevanten Attribute herausprojiziert und umbenannt werden: ctnpartner = ctnpartner′ = P ROJ[prn, concept]proplet REN [prn, ctnconcept]ctnpartner verbproplet′ = verbproplet LEF T OU T ER JOIN [verbproplet.ctn = ctnpartner′ .prn] ctnppartner′ Somit besitzt das Resultat folgendes Schema: verbproplet′ (prn, wdn, concept, sur, epi, lang, ctn, ctncnj, ctnconcept) ctp: Um ctp darstellen zu können, müssen einerseits die Propositionsnummer und das Konzept ermittelt werden, das das Verbproplet der vorigen Proposition besitzt, andererseits die mögliche Konjunktion bestimmt werden. Als Basis dafür lässt sich folgende Zwischenrelation einführen, die natürlich auch die Attribute beinhalten muss, die im anschließenden Join in der Restriktion vorkommen. Auch ctp ist nicht notwendigerweise nicht-null, so dass ein Outer-Join angewendet wird. 38 ctppartner = ctppartner′ = P ROJ[prn, concept, ctn, ctncnj]verbproplet REN [ctp, ctpconcept, ctn, ctpcnj]ctppartner verbproplet′′ = verbproplet′ LEF T OU T ER JOIN [verbproplet′ .prn = ctppartner′ .ctn] ctpartner′ Die finale Relation verbproplet” hat also folgendes Schema: verbproplet′′ (prn, wdn, concept, sur, epi, lang, ctn, ctnconcept, ctncnj, ctp, ctpconcept, ctpcnj) mdr: mdr stellt seitens JLAG ein mengenwertiges Attribut dar. Wie oben beschrieben wird daher eine separate Anfrage erstellt. Diese muss eine Selektion bezüglich eines bestimmten Wertes für prn beinhalten. Für die Ausgabe wird jedoch nur das Konzept des Adverbs benötigt, so dass anschließend eine Projektion durchgeführt wird. verbmdr = P ROJ[concept](SEL[prn = x]adverbialproplet) arg: Für die Rekonstruktion von arg genügt analog zu mdr ein Teil der entsprechenden Relation nounproplet, der sich wie folgt spezifizieren lässt: verbarg = P ROJ[concept, argn](SEL[prn = x]nounproplet) Das Attribut argn wird in der Projektionsliste benötigt, da, wie oben schon beschrieben, die Reihenfolge der einzelnen Argumente relevant ist. sem und cat: Die Behandlung von verbsem und verbcat geschieht aufgrund ihres nahezu identischen Aufbaus analog. Ebenso wie bei mdr und arg muss auch hier nur eine Selektion auf die Werte von prn und wdn angewendet werden, um die einzelnen Bestandteile von sem und cat für ein proplet zu erhalten. In einer höheren Schicht, das heißt, auf Programmiersprachenebene, müssen dann aus diesen Werten die eigentlichen JLAG-Attribute sem und cat rekonstruiert werden; dort erlangen auch die Werte semcatn und semn/catn ihre Bedeutung, da hier Positionsangaben in der Liste der einzelnen Bestandteile gespeichert ist. verbsemvalues = SEL[prn = x]verbsem verbcatvalues = SEL[prn = x]verbcat Nomina In der Relation nounproplet sind die Attribute fnc, mdr, sem und cat nicht wie in JLAG enthalten, so dass diese extra ermittelt werden müssen. Dies geschieht wie folgt: fnc: Dies ist das einzige der fehlenden Attribute, das nicht mengenwertig ist. Somit wird für die Ermittlung der korrekten Werte ein Join durchgeführt. Dieser basiert einerseits natürlich auf nounproplet, andererseits auf einer Relation, die sich wie folgt festlegen lässt: f ncpartner = REN [prn, f nc](P ROJ[prn, concept]verbproplet) concept stellt den eigentlichen Wert von fnc dar, wohingegen prn für den anschließenden Join benötigt wird: nounproplet′ = nounpropletJOIN [nounproplet.prn = f ncpartner.prn]f ncpartner nounproplet′ (prn, wdn, concept, sur, idy, argn, f nc) mdr: Die Berechnung erfolgt analog zu mdr bei Verbproplets. Der einzige Unterschied besteht darin, dass für die eindeutige Identifikation eines Nounproplets die Werte für prn und wdn benötigt werden. nounmdr = P ROJ[concept](SEL[prn = x, wdn = y]nounproplet) sem und cat: Bis auf die fehlende Projektion sieht es im Falle von nounsem und nouncat genauso aus: 39 nounsemvalues = SEL[prn = x, prn = y]nounsem nouncatvalues = SEL[prn = x, prn = y]nouncat Adverbien Gegenüber einem JLAG-Adjektivproplet fehlt der Relation adverbialproplet außer sem, cat und trc, die sich analog zu sem und cat bei Nomina berechnen lassen, nur das Attribut mdd. Da zu jedem Adverb stets nur ein Modifikand, das heißt Verb, existiert, wird sein Konzept über die Durchführung eines Join der Relation adverbialproplet hinzugefügt: mddverbpartner = REN [prn, mdd](P ROJ[prn, concept]verbproplet′′ ) adverbialproplet′ = adverbialproplet JOIN [adverbialproplet.prn = mddverbpartner.prn] mddverbpartner Somit hat adverbialproplet’ folgendes Schema: adverbialproplet′ (prn, wdn, concept, sur, mdd) Die Bestimmung von sem und cat geschieht durch Ausdrücke der Form advsemvalues = SEL[prn = x, prn = y]advsem advcatvalues = SEL[prn = x, prn = y]advcat Adnomina Auch für Adnomina muss noch die Oberfläche des Modifikanden ermittelt werden. Diese ist in der Relation nounproplet enthalten; natürlich könnte hier auch, genau wie schon in einigen der anderen Fälle, proplet verwendet werden. Der nötige Join zielt auf die Fremdschlüsselbeziehung (prn,mddnoun) ab, so dass folgender Term das gewünschte Ergebnis bringt: mddnounpartner = REN [prn, wdn, mdd](P ROJ[prn, wdn, concept]verbproplet) adnominalproplet′ = adnominalproplet JOIN [adnominalproplet.prn = mddnounpartner.prn adnominalproplet.wdn = mddnounpartner.wdn] mddnounpartner Für die resultierende Relation ergibt sich dementsprechend folgendes Bild: adnominalproplet′ (prn, wdn, concept, sur, mdd) Wie auch schon bei Adverbien lassen sich die Werte der restlichen Attribute sem, cat und trc wie bei noun bestimmen. adnsemvalues = SEL[prn = x, prn = y]adnsem adnncatvalues = SEL[prn = x, prn = y]adncat 5.3.4 Ermitteln spezieller Proplets Durch Anwendung der obigen Ausdrücke lassen sich die vollständigen Mengen der Verben, Nomina, Adverbien und Adnominale durch Benutzung der entsprechenden Terme ermitteln; für die Darstellung der in 3.3 aufgeführten Zugriffe auf die Datenbank müssen nur weitere Selektionen auf diese Mengen angwendet werden. Wenn in JLAG von einem Verbproplet zu einem seiner Argumente navigiert werden soll, dann beinhaltet die entsprechende Suchbedingung an der Datenbankschnittstelle die Propositionsnummer und das Konzept des Argumentproplets. Unter der Annahme, dass das Nomen mit dem Konzept katze“ in der ” 40 AN D Proposition mit der Nummer 3 gesucht wird, lautet der entsprechende Ausdruck der relationalen Algebra unter Verwendung der oben eingeführten Relationen: SEL[prn = 3, concept = katze]nounproplet′ Auf diese Weise können alle relevanten Anfragen abgewickelt werden. Dies wird in Kapitel 8.2.2 genauer behandelt. 5.4 Abschließende Bemerkungen Die oben beschriebenen Terme der relationalen Algebra sind Schritt für Schritt entwickelt worden, um einen verständlichen Überblick über die Methodik der Anfragestellung zu geben; in der tatsächlichen Implementierung werden sich diese jedoch nicht unbedingt 1:1 wiederfinden lassen, da man viele Ausdrücke zusammenfassen kann. In den folgenden Kapitel wird auch auf diesen Aspekt eingegangen werden. 41 42 6 Physischer Entwurf Als letzter Schritt im Designprozess steht nun die Implementierung der Datenbank in einem konkreten System an. Im Rahmen dieser Arbeit wird dies MySQL 4.0 sein. Wie schon erwähnt bedarf die Umsetzung des konzeptionellen Schemas im relationalen Kontext nicht viel Arbeit: Die schon definierten Relationen müssen einfach mit Hilfe einer Definitionssprache ins System eingebracht werden; zusätzlich müssen nur anwendungsorientierte Optimierungen und systemspezifische Erfordernisse berücksichtigt werden. 6.1 MySQL MySQL ist das am weitesten verbreitete Open-Source-Datenbanksystem im relationalen Sektor. Sie ist für eine Vielzahl von Plattformen vefügbar und bietet eine weitgehende Unterstützung der Standard-Anfragesprache SQL. Die Hauptkomponente stellt ein Datenbankserver dar. Dieser lässt sich zum Beispiel mit passenden Treibern aus Anwendungsprogrammen heraus nutzen, aber auch per mitgelieferter Client-Software im Konsolenbetrieb; das bedeutet, dass SQL-Kommandos direkt an einer Kommandozeile eingegeben werden können. Lange Zeit fehlten MySQL viele Merkmale, die vom SQL92-Standard definiert sind und kommerzielle Datenbanksysteme schon längere Zeit boten. Mittlerweile ist jedoch zumindest das Konzept der Transaktionen integriert. Die Entwicklung in Richtung des Standards ist bei weitem nicht abgeschlossen; unter anderem fehlen die sogenannten Sichten, die auch im Rahmen der vorliegenden Arbeit von Nutzen wären, und auch Unteranfragen sind in den derzeit finalen Versionen nicht möglich1 . 6.2 SQL Im Bereich der relationalen Datenbanksysteme ist die Structured Query Lan” guage“ die de-facto-Standardsprache. Basierend auf ersten Implementierungen bei IBM Anfang der 70er-Jahre im Rahmen des ersten relationalen Systems namens System R fand ein bis heute andauernder Entwicklungsprozess statt, der zu einer absoluten Dominanz von SQL am Markt geführt hat. Mittlerweile existieren drei ANSI-Standards SQL 1 von 1990, SQL 2 (1992) und SQL 3 (1999). Letzterer bietet objekt-relationale Erweiterungen, die jedoch für diese Arbeit keine Rolle spielen, da die Implementierung in einem rein relationalen System geschehen soll. Die Referenz für die derzeitig aktuelle Version 4.0 von MySQL stellt somit der nach dem Erscheinungsjahr auch SQL-92 genannte Standard dar. 1 siehe hierzu die Entwicklungs-Roadmap in der MySQL-Dokumentation 43 SQL besteht aus den drei Teilen DDL, DML und DCL. Das Akronym DDL steht für Data Definition Language“. Mit ihrer Hilfe lassen sich die Relatio” nen, Sichten, Indexe etc. in der Datenbank anlegen und bearbeiten.2 Die DML ( Data Manipulation Language“) bietet Operationen zum Bearbeiten ” der eigentlichen Nutzdaten wie zum Beispiel Such-Anfragen, Einfügen, Modifizieren und Löschen. Dieser Teil von SQL implementiert also unter anderem grundsätzlich die relationale Algebra. Der Data Control Language“, der dritte Teil, bietet Funktionen zur Benutzer” und Rechte-Verwaltung. Dies spielt jedoch in der vorliegenden Arbeit nur eine untergeordnete Rolle, so dass an dieser Stelle auf die weiterführende Literatur verwiesen wird. Diese Phase der Datenbankentwicklung bedeutet also die Benutzung der DDL, um die im Verlauf der vorangegangenen Kapitel entwicktelten Relationen samt einiger systembedingter Optionen zu implementieren. Daher folgt nun eine Beschreibung der nötigen Kommandos dieses SQL-Teiles; die DCL soll später erklärt werden, wenn die Benutzung der Datenbank, das heißt, die Implementierung der Anfragen behandelt wird. 6.2.1 Operatoren der DDL Die wichtigste Funktion der DDL besteht im Anlegen von Relationen. Diese Aufgabe wird vom CREATE TABLE“-Kommando übernommen. Folgende ” EBNF-Beschreibung definiert einen Teil seiner Syntax, der für diese Arbeit genügt: CREATE TABLE tablename ( elementdefinition,...); elementdefinition: spaltenname datentyp [NOT NULL] | PRIMARY KEY (spaltenname,...) | INDEX (spaltenname,...) | UNIQUE (spaltenname,...) | FOREIGN KEY (spaltenname,...) REFERENCES tablename [ON DELETE option] [ON UPDATE option] | CHECK (ausdruck) Mit PRIMARY KEY“ werden Primärschlüssel definiert, mit FOREIGN KEY“ ” ” Fremdschlüssel. Für letztere lässt sich festlegen, was geschehen soll, wenn ein referenziertes Tupel gelöscht wird ( ON DELETE“) oder sich sein Schlüsselwert ” ändert ( ON UPDATE“): Im Falle der Option CASCADE“ wird die Löschung ” ” beziehungsweise Änderung auch auf das referenzierende Tupel angewendet, mit SET NULL“ wird in beiden Fällen der Wert der Fremdschlüsselattribute auf ” null gesetzt. Als dritte Möglichkeit existiert RESTRICT“, mit dem die ge” samte Modifikation zurückgewiesen wird. Welche Alternative bevorzugt wird, hängt von der Anwendungswelt ab. Über INDEX“ lassen sich Indexe erstellen, durch die Anfragen, die die auf” geführten Attibute betreffen, beschleunigt werden können. UNIQUE“ spezifi” ziert, dass Werte eines Attributs jeweils nur einmal vorkommen. Mit CHECK“ ” lassen sich Regeln der Anwendungswelt in die Datenbank einbringen. NOT ” NULL“ legt fest, dass das betroffene Attribut in keinem Tupel der Relation unausgefüllt, also null sein darf. Der SQL-Standard spezifiziet auch Datentypen. Die für diese Anwendung wichtigsten sind für Zahlenwerte INTEGER und SMALLINT (auch mit Zusatz 2 In SQL wird eine Relation als table“ bezeichnet. Dieser Begriff wird im folgenden synonym ” benutzt. 44 UNSIGNED, was zu einem komplett positiven Wertebereich führt); für Zeichenketten wird VARCHAR mit der Zahl der möglichen Zeichen als Parameter benutzt. Beispielsweise fügt folgendes Statement der Datenbank eine Relation namens KFZ hinzu, deren Primärschlüsel fahrgestellnummer“ ist und über ein Fremd” schlüsselattribut Besitzer“ eine Relation Person referenziert.3 ” CREATE TABLE kfz ( fahrgestellnummer INTEGER , hersteller VARCHAR(20), modell VARCHAR (10), kennzeichen VARCHAR(10), besitzer INTEGER, PRIMARY KEY (fahrgestellnummer), FOREIGN KEY (besitzer) REFERENCES person ON DELETE SET NULL ON UPDATE CASCADE, UNIQUE kennzeichen ); Falls ein KFZ-Besitzer aus der Datenbank entfernt wird, soll der Wert des Fremdschlüsselattributs, das ihn referenziert, auf null gesetzt werden; dies wird durch ON DELETE SET NULL“ festgelegt. Wenn sich der Primärschlüssel” wert eines referenzierten Tupels in person ändert, soll der Wert von besitzer“ in ” kfz angepasst werden. Diese beiden Regeln begründen sich in der Anwendungswelt. Auch über die UNIQUE-Zeile wird eine Regel aus der nachzubildenden Miniwelt eingebracht, die besagt, dass Kennzeichen eindeutig sein müssen.4 Ebenso existieren CREATE-Kommandos für Sichten (Views). Views sind im Prinzip nichts anderes als in der Datenbank gespeicherte DML-Anfragen. Sie können in Statements wie Tables verwendet werden; erst bei ihrer Benutzung, also nicht bei ihrer Definition, wird das Statement ausgeführt. Somit ergibt sich stets ein aktuelles Bild der Relationen, die von der Anfrage betroffen sind, ohne dass der Update-Aufwand bei Erstellung einer zusätzlichen Relation anfallen würde. Hierin besteht neben der kompakteren Anfrageformulierung für den End-Benutzer auch der Hauptvorteil von Sichten. Zusätzlich schaffen Sichten auch eine zusätzliche Abstraktionsebene, die es erlaubt, individuell angepasste Schemata für verschiedene Benutzergruppen anzubieten. Die Syntax einer View-Definition stellt sich vereinfacht folgendermaßen dar: CREATE VIEW viewname AS anfrage; Der zweite Hauptoperator der DDL ist der ALTER“-Befehl. Natürlich ist seine ” wichtigste Erscheinungsform die in einem ALTER TABLE“-Statement. Da” mit lassen sich Relationenschemata nachträglich modifizieren, das heißt, zum Beispiel Attribute hinzufügen, Indexe erstellen, Schlüssel definieren oder Constraints ändern. Die wichtigsten Teile seiner Syntax werden durch folgendes EBNF-Fragment beschrieben: ALTER TABLE tablename aenderungsdefinition [, aenderungsdefinition ...]; aenderungsdefinition: ADD elementdefinition | ADD (elementdefinition, elementdefinition,...) | ADD INDEX [indexname] (spaltenname,...) 3 Hier wird die der Besitzer als Integer-Identitätsnummer dargestellt. Somit hat auch dieses Attribut die Schlüsseleigenschaft und könnte als Primärschlüssel dienen. Jedoch sind Zeichenkettenattribute aus Performanzgründen wenn möglich nicht zu bevorzugen. 4 45 | | | | | | | ADD PRIMARY KEY (spaltenname,...) ADD UNIQUE (spaltenname,...) ADD FOREIGN KEY (spaltenname) REERENCES tablename MODIFY elementdefinition DROP spaltenname DROP PRIMARY KEY DROP INDEX indexname Beispielsweise wird mit folgendem ALTER TABLE“-Statement der oben ge” nannten KFZ-Table ein Attribut farbe“ hinzugefügt: ” ALTER TABLE kfz ADD farbe VARCHAR(20); Eine ausführliche Dokumentation hierfür genau wie für die anderen Operatoren liefert die angegebene Literatur. 6.2.2 Implementierung der WURM-Relationen Hauptsächlich besteht die Implementierung der für diese Arbeit erdachten Relationen also in der einfachen Benutzung von CREATE-Statements mit den jeweiligen Schemata. Es wurde darauf geachtet, nur SQL-konforme Datentypen zu verwenden. Zwar bietet wie praktisch alle großen Datenbanksystem auch MySQL einen erweiterten Satz, jedoch werden dadurch Portabilität und Verständlichkeit beeinträchtigt. Spalten, die in jedem Tupel einen Wert aufweisen müssen, sollten unbedingt mit der NOT NULL“-Einschränkung versehen werden, um die logischen Inte” grität der Daten zu gewährleisten. Betroffen sind alle Attribute bis auf die der folgenden drei Gruppen: • sur in proplet und lang und epi in verb werden momentan nicht genutzt und müssen daher nullwertig sein dürfen. • ctncnj und ctn in verb sind optional, da Propositionen nicht immer Nachfolger besitzen und mit diesen nicht immer über Konjunktionen verknüpft sein müssen. • Primärschlüssel-Attribute dürfen von Natur aus nicht null sein. Somit entfällt auch für sie die zusätzliche Spezifikation. Somit lassen sich durch folgende Standard-konforme Kommandos die gewünschten Relationen erstellen: 46 CREATE TABLE proplet ( prn INTEGER, wdn SMALLINT UNSIGNED, sur VARCHAR (20), concept VARCHAR(20) NOT NULL, PRIMARY KEY (prn, wdn) ); CREATE TABLE trc ( prn INTEGER, wdn SMALLINT UNSIGNED, timestamp INTEGER NOT NULL, PRIMARY KEY (prn, wdn, timestamp), FOREIGN KEY (prn, wdn) REFERENCES proplet(prn, wdn) ); CREATE TABLE verb ( prn INTEGER, wdn SMALLINT UNSIGNED, epi BIT, lang BIT, ctn INTEGER, ctncnj VARCHAR(20), PRIMARY KEY (prn), FOREIGN KEY (prn, wdn) REFERENCES proplet(prn, wdn) FOREIGN KEY (ctn) REFERENCES verb(prn) ); CREATE TABLE adverbial ( prn INTEGER, wdn SMALLINT UNSIGNED, PRIMARY KEY (prn, wdn), FOREIGN KEY (prn, wdn) REFERENCES proplet(prn, wdn) FOREIGN KEY (prn) REFERENCES verb(prn) ); CREATE TABLE noun ( prn INTEGER, wdn SMALLINT UNSIGNED, idy INTEGER NOT NULL, argn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY (prn, wdn), FOREIGN KEY (prn, wdn) REFERENCES proplet(prn, wdn), FOREIGN KEY (prn) REFERENCES verb(prn) ); CREATE TABLE adnominal ( prn INTEGER, wdn SMALLINT UNSIGNED, mddnoun SMALLINT UNSIGNED NOT NULL, PRIMARY KEY (prn, wdn), FOREIGN KEY (prn, wdn) REFERENCES proplet (prn, wdn), FOREIGN KEY (prn, mddnoun) REFERENCES noun(prn, wdn) ); CREATE TABLE verbsem ( prn INTEGER, semcatn SMALLINT UNSIGNED NOT NULL, semvalue VARCHAR(20) NOT NULL, semn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, semcatn, semn ), FOREIGN KEY ( prn ) REFERENCES verb(prn) ); CREATE TABLE verbcat ( prn INTEGER, semcatn SMALLINT UNSIGNED NOT NULL, catvalue VARCHAR(20) NOT NULL, catn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, semcatn, catn ), FOREIGN KEY ( prn ) REFERENCES verb(prn) ); CREATE TABLE advsem ( prn INTEGER, 47 wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, semvalue VARCHAR(20) NOT NULL, semn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, semn ), FOREIGN KEY ( prn, wdn ) REFERENCES adverbial(prn, wdn) ); CREATE TABLE advcat ( prn INTEGER, wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, catvalue VARCHAR(20) NOT NULL, catn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, catn ), FOREIGN KEY ( prn, wdn ) REFERENCES adverbial(prn, wdn) ); CREATE TABLE nounsem ( prn INTEGER, wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, semvalue VARCHAR(20) NOT NULL, semn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, semn ), FOREIGN KEY ( prn, wdn ) REFERENCES noun(prn, wdn) ); CREATE TABLE nouncat ( prn INTEGER, wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, catvalue VARCHAR(20) NOT NULL, catn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, catn ), FOREIGN KEY ( prn, wdn ) REFERENCES noun(prn,wdn) ); CREATE TABLE adnsem ( prn INTEGER, wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, semvalue VARCHAR(20) NOT NULL, semn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, semn ), FOREIGN KEY ( prn, wdn ) REFERENCES adverbial(prn,wdn) ); CREATE TABLE adncat ( prn INTEGER, wdn SMALLINT UNSIGNED, semcatn SMALLINT UNSIGNED NOT NULL, catvalue VARCHAR(20) NOT NULL, catn SMALLINT UNSIGNED NOT NULL, PRIMARY KEY ( prn, wdn, semcatn, catn ), FOREIGN KEY ( prn, wdn ) REFERENCES adnominal(prn,wdn) ); Die ON UPDATE“- und ON DELETE“-Spezifikationen wurden in obiger ” ” 48 Auflistung aus Gründen der Übersichtlichkeit nicht mit aufgeführt; für den Fremdschlüssel ctn“ gilt SET NULL“ bei Löschungen, ansonsten stets ON ” ” ” DELETE CASCADE ON UPDATE CASCADE“.5 Nun empfiehlt es sich, Indexe anzulegen, um die anwendungsspezifischen Anfragen schneller ausführen zu können. Dies geschieht für die Attribute concept in der Table proplet und idy in noun, da Suchanfragen vor allem auf deren Werte abzielen; außerdem erscheint ein Index für ctn in der Relation verb sinnvoll. CREATE INDEX conceptindex ON proplet(concept); CREATE INDEX idytindex ON noun(idy); CREATE INDEX ctntindex ON verb(ctn); Leider müssen bei der Verwendung von MySQL einige Besonderheiten beachtet werden: • Da die Benutzung der transaktionalen Fähigkeiten von MySQL 4.0 gerade im Hinblick auf die folgenden, komplexen Einfügevorgänge wünschenswert ist, sollte auf die sogenannten InnoDB-Tables zurückgegriffen werden. Diese bieten eine ACID-konforme6 Anfrageverarbeitung. InnoDB bietet als erster Speicherungsmanager in MySQL auch die Gewährleistung von FOREIGN KEY“- Bestimmungen. ” Die Verwendung dieses Table-Typs muss aber explizit festgelegt werden, da ansonsten ein anderer Typ benutzt wird. ALTER TABLE proplet TYPE = InnoDB; ALTER TABLE TYPE = InnoDB; ... • MySQL fordert in Verbindung mit InnoDB das explizite Anlegen von Indexen über Attributen, deren Werte mit FOREIGN KEY“-Attributen in ” anderen Relationen referenziert werden. Auch die Fremdschlüsselattribute selbst müssen indexiert werden. Da durch Primärschlüssel-Definitionen automatisch Indexe angelegt werden, betrifft dies jedoch nur wenige Stellen der CREATE-Statements; und auch wenn die Fremdschlüsselattribute einen Teil eines vorhandenen Indexes darstellen, muss keine zusätzliche Definition vorgenommen werden. Somit sind die folgenden Ergänzungen nötig: CREATE INDEX prnwdnVerbIndex ON verb (prn, wdn); CREATE INDEX ctnVerbIndex ON verb (ctn); CREATE INDEX prnmddNounIndex ON noun (prn, mddnoun); All diese zusätzlichen Festlegungen können in MySQL schon bei der Erstellung der Relationen getroffen werden. Zum Beispiel geschieht die Definition des Tabletyps durch seine Angabe am Ende eines CREATE TABLE“-Kommandos, ” im vorliegenden Fall durch das Anhängen von TYPE = InnoDB“ hinter der ” letzten schließenden Klammer. Bevor die Relationen mit den gerade gezeigten Statements erstellt werden können, muss jedoch noch eine Datenbank definiert werden, der die Tables angehören sollen. Dies geschieht ebenfalls durch ein CREATE-Kommando, das jedoch deutlich kürzer ausfällt. Im folgenden wird davon ausgegangen, dass mit CREATE WURM; 5 Diese Festlegungen sind aber eher zweitrangig, da Änderungen der Primärschlüssel praktisch nicht vorkommen und Löschungen stets die gesamte Datenbank betreffen. 6 Alles oder nichts“-Prinzip bei Modifikationen des Datenbestandes. Siehe hierzu die ange” gebene Datenbankenliteratur 49 eine Datenbank angelegt namens WURM wurde, in der die Relationen definiert sind. Außerdem können mit Hilfe von Kommandos der DCL neue Nutzer erstellt werden; standardmäßig existiert in MySQL der Benutzer root“. Die” ser Name hat jedoch nichts mit dem des Administrators in Unixsystemen zu tun. root“ kann jeder Benutzer sein. Dennoch ist es natürlich wünschenswert, ” verschiedene Log-ins mit verschiedenen Rechten zu benutzen. 6.2.3 Operatoren der DCL Die beiden Hauptkommandos der DCL sind GRANT“, mit dem sich Rechte ” vergeben lassen, und REVOKE“, durch dessen Anwendung Rechte entzogen ” werden können. GRANT“ besitzt folgende Syntax: ” GRANT privilegien [(spalten)] [, privilegien [(spalten)] ...] ON {datenbank.table | *.* } TO benutzerername IDENTIFIED BY passwort [WITH GRANT OPTION]; Mit solchen Statements lassen sich auch neue Benutzer hinzufügen, denen dann über die IDENTIFIED BY“-Klausel ein Passwort zugewiesen wird, mit dem ” sie sich anmelden müssen. Mögliche Privilegien sind z.B. bestimmte DMLOperatoren ausführen zu können, aber auch administrative Rechte zum Löschen oder Erstellen von ganzen Tables. Folgendes Statement erstellt einen neuen Benutzer namens moritz, der sich mit dem Passwort katze“ anmelden muss. Er ” soll sämtliche Rechten auf allen Tables aller Datenbanken besitzen und selbst GRANT-Kommandos benutzen dürfen: GRANT ALL PRIVILEGES ON *.* TO moritz@localhost IDENTIFIED BY ’katze’ WITH GRANT OPTION; REVOKE“-Statements sind ähnlich aufgebaut: ” REVOKE privilegien [(spalten)] [, privilegien [(spalten)] ...] ON {table | * } FROM benutzerername; Auf eine weitergehende Erläuterung soll an dieser Stelle verzichtet werden, da die DCL für die vorliegende Arbeit eine untergeordnete Rolle spielt. 50 Die Rekonstruktion von Proplets mit SQL 7 Ein wichtiges Charakteristikum von SQL ist die Mengenorientierung: Argumente und Resultate praktisch aller Operationen der DML1 sind Mengen2 . Besonders hervorzuheben ist auch die Tatsache, dass Anfragen deskriptiv formuliert werden, das heißt, es muss nicht angegeben werden, wie, sondern nur welche Daten gesucht werden sollen. Durch diesen höheren Grad an Abstraktion erleichtert sich die Benutzung für den Nutzer erheblich. In diese Kerbe schlägt auch der Ansatz der Entwickler von SQL, die Sprache durch Verwendung von möglichst natürlichsprachlichen Kommandos verständlich zu gestalten. Ob diese Absicht erfolgreich umgesetzt wurde, sei dahingestellt. In SQL stellt die Data Manipulation Language“ (DML) die Kommandos zur ” Anfrageformulierung zur Verfügung. Die folgende Beschreibung der einzelnen Operatoren soll Aufschluss über ihre Funktionalität und Verwendung geben. 7.1 Operatoren der DML Die DML umfasst Kommandos zum Abfragen, Modifzieren, Löschen und natürlich notwendigerweise auch Einfügen von Daten. Die folgenden Unterkapitel erläutern Syntax und Funktion der relevanten SQL-Statements. 7.1.1 Suchanfragen Der Funktionsumfang von Suchanfragen besteht in großen Teilen in dem der relationalen Algebra. Daher finden deren Operatoren in SQL jeweils entsprechende Konstruktionen. Projektionen Der DML-Operator SELECT implementiert die Projektion. Der relationale Ausdruck P ROJ[attribut1, attribut2]relation entspricht in SQL dem Statement SELECT FROM attribut1, attribut2 relation; FROM“ legt also die Eingaberelation fest. Es sind jedoch auch mehrere Aus” gangstables möglich. Um dann unter Umständen gleichnamige Attribut un1 2 Bis auf die Einfügeoperation INSERT, welche Tupel-orientiert funktioniert Darin zeigt sich die Verbindung zur relationalen Algebra. 51 terscheiden zu können, wird eine Punktnotation benutzt, wie sie in ähnlicher Weise auch in Sprachen wie C verwendet wird. SELECT FROM relation1.attribut1, relation2.attribut2 relation1, relation2; Es besteht die Möglichkeit, Tables in der FROM-Klausel Aliasnamen zu erteilen, da unter Umständen eine Relation mehrmals vorkommt. Diese zusätzlichen Bezeichnungen werden direkt hinter dem Relationennamen aufgeführt. Ebenso lassen sich Attribut für das Ergebnis einer Anfrage umbenennen. Dies geschieht durch Benutzung von AS“. ” SELECT FROM attribut AS neuername relation; Besondere Aufmerksamkeit sollte man der Tatsache widmen, dass das SELECTKommando nicht der relationalen Selektion, sondern der Projektion entspricht, auch wenn der Name dies sehr leicht vermuten lässt. Die Selektion geschieht über den sogenannten WHERE-Operator. Selektion WHERE“ dient dazu, Restriktion auf Relationen durchzuführen. Anwendung ” findet dieses Kommando u.a. im Rahmen eines SELECT-Statements; ein Ausdruck der relationalen Algebra der Form SEL[attribut = wert]relation wird auf SELECT * FROM relation WHERE attribut = wert; abgebildet. Durch SELECT *“ wird keine eigentliche Projektion durchgeführt, ” da alle Attribute (durch ’*’) in der Ergebnisrelation vorkommen. Doch natürlich lassen sich so auch Projektion und Selektion kombinieren, wie folgendes Beispiel zeigt: SELECT FROM WHERE AND AND besitzer, kennzeichen kfz hersteller = ’VW’ modell = ’Golf’ farbe = ’gruen metallic’; Wie gerade demonstriert, erlaubt also genau wie der relationale Restriktionsoperator auch WHERE“ boolesch verknüpfte, komplexe Selektionsbedingun” gen. Selbstverständlich sind nicht nur Attribut-Wert-, sondern auch AttributAttribut-Vergleiche zulässig. Joins In SQL gibt es für den entsprechenden relationalen Operator das Kommando JOIN“. Es lässt sich in Statements der folgenden Form verwenden: ” SELECT FROM 52 attributliste relation1 [NATURAL] [ [LEFT|RIGHT] OUTER] JOIN relation2 ON relation1.attribut2 vergleichsoperator relation2.attribut2; Die Bedeutung der optionalen Parameter ergibt sich in Kapitel 5.1.2. Unter Verwendung der oben eingeführten Table kfz und einer zusätzlichen namens Person mit der Definition CREATE TABLE person ( personID INTEGER, vorname VARCHAR(16), nachname VARCHAR(20), PRIMARY KEY(personID) ); lässt sich am folgenden Statement eine typische Verwendung von JOIN demonstrieren: SELECT FRO WHERE person.nachname AS besitzer kfz JOIN person ON kfz.besitzer = person.personID kennzeichen = ’N-IL 000’; Da sich gemäß seiner Definition in der relationalen Algebra der Join zweier Relationen auf das kartesische Produkt dieser mit anschließender Selektion zurückführen lässt, kann man obiges Statement auch folgendermaßen umformulieren: SELECT FROM WHERE AND person.nachname AS besitzer kfz, person kfz.besitzer = person.personID kennzeichen = ’N-IL 000’; Die ersten beiden Zeilen alleine bedeuten nämlich die Durchführung des kartesischen Produkts der beiden Tables. Die Durchführung eines Join hat ihre größte Bedeutung in der Kombination von Tupeln, die über eine Fremdschlüsselbeziehung verknüpft sind; somit hat dieser Operator für diese Arbeit eine enorme Bedeutung. Division In SQL gibt es für die Division kein eigener Operator; vielmehr muss dessen Funktionalität über ein sehr komplexes Statement basierend auf anderen Kommandos nachgebildet werden. Da die Division verhältnismäßig selten benötigt wird und vor allem auch in der zu entwickelnden Datenbank keine Rolle spielen wird, soll auf dessen Erläuterung verzichtet werden. Zusammenfassung DML-SELECT Über diese vier relationalen Operatoren hinaus gibt es noch eine Menge weiterer Kommandos, die in Anfragen verwendet werden können; die wichtigsten zeigt schematisch folgender Ausschnitt der Syntax von SELECT-Statements: SELECT selectausdruck,... [FROM tableausdruck [WHERE selektionsbedingung] [GROUP BY spaltenname, ...] [HAVING selektionsbedingung] [ORDER BY spaltenname [ASC | DESC] ,...]; Mit GROUP BY“ lassen sich Tupel nach der Restriktion durch WHERE grup” pieren. Die nachfolgenden Operationen beziehen sich dann auf die resultierenden Gruppen. Zum Beispiel kann anschließend durch HAVING“ eine weitere ” Selektion angewendet werden, die nun aber eben bestimmte Gruppeneigenschaften berücksichtigen kann: Hierfür gibt es die sogenannten Aggregatsfunktionen wie 53 • max(): Maximumsberechnung bestimmter Attribute bezüglich Gruppen • min(): Minimumsberechnung - “ • avg(): Durchschnittsberechnung - “ • count(): Zählen von Tupeln in Gruppen • ... Diese Funktionen können aber auch in Projektions-Klauseln verwendet werden. Folgendes Statement zeigt einen typischen Verwendungsfall der zuletzt beschriebenen Operatoren: SELECT FROM GROUP BY HAVING besitzer kfz besitzer count(*) > 1; Diese Anfrage unter Verwendung der auch schon in den oben aufgeführten Beispielen Relation kfz liefert alle Autobesitzer, auf die mehr als ein Auto zugelassen ist. Um eben diese Anzahl der Autos pro Besitzer auch in der Ausgabe anzuzeigen, müsste die Projektionszeile in SELECT besitzer, count(*)“ ” geändert werden. Durch ORDER BY“ lassen sich Tupel für die Ausgabe auf-(ASC) oder ab” steigend (DESC) sortieren. Dies geschieht nach der möglichen Anwendung von Selektion und Gruppierung. Folgende Anfrage listet also alle Zweitwagenbesitzer beginnend mit demjenigen mit den meisten Autos auf: SELECT besitzer, count(*) as kfzanzahl FROM kfz GROUP BY besitzer HAVING count(*) > 1 ORDER BY kfzanzahl DESC; Die Sortierung gehört nicht zum Funktionsunfang der relationalen Algebra; genau genommen widerspricht sie ihr sogar, da Relationen Mengen entsprechen und somit die Reihenfolge der Elemente keine Rolle spielt. 7.1.2 Modifikationen Zur Änderung von Daten bietet die DML das UPDATE-Statement. Seine Syntax ist wie folgt definiert: UPDATE SET tablename spaltenname1=ausdruck1 [, spaltenname2=ausdruck2 ...] [WHERE selektionsbedingung]; Mit dem im Rahmen der Suchanfragen schon behandelten WHERE-Kommando lässt sich festlegen, welchen Bedingungen Tupel unterliegen müssen, damit sie modifiziert werden. Eine Anwendung eines UPDATE-Statement im Rahmen der eingeführten Relationen wird zum Beispiel im Falle einer Ummeldung eines Autos nötig: UPDATE SET WHERE 54 kfz kennzeichen = ’S-QL 92’, besitzer = 23 fahrgestellnummer = 12345678; 7.1.3 Löschungen Das Löschen von Tupeln geschieht mit dem DELETE-Kommando, das folgendermaßen aufgebaut ist: DELETE FROM tablename [WHERE selektionsbedingung]; Beispielsweise lässt sich mit DELETE FROM kfz WHERE fahrgestellnummer = 12345678; ein Automobil aus der Relation kfz entfernen. 7.1.4 Einfügungen Das INSERT-Statement ermöglicht das Einfügen von Tupeln in Relationen. INSERT INTO tablename [(spaltenname,...)] VALUES (wert,...); Durch die Angabe der Reihenfolge der Spaltennamen nach dem Relationennamen wird festgelegt, welchen Attributen die Werte in der VALUES-Liste zuzuordnen sind. Erfolgt keine Angabe, wird als Reihenfolge die im CREATE ” TABLE“- Statement angenommen. Die Anzahl der Attribute muss mit der der Werte übereinstimmen. Folgende Anweisung erweitert die Relation Person um eine Zeile mit den Attributwerten 22 für personID, ’Tim’ für Vorname und ’Berners-Lee’ für Nachname. INSERT INTO person (nachname, vorname, personID) VALUES (’Berners-Lee’, ’Tim’, 22); Natürlich müssen die einzufügenden Werte mit den Datentypen der Attribute kompatibel sein. 7.2 Die Basisanfragen in SQL Auf Basis der gerade beschriebenen Kommandos lassen sich nun die in Kapitel 5.3 beschriebenen Terme der relationalen Algebra in SQL umsetzen. Wie dort schon erwähnt, werden diese Anfragen jedoch nicht 1:1 umgesetzt, da sich bestimmte Teilausdrücke zusammenfassen und sich so übersichtlichere DMLStatements erstellen lassen. Im Folgenden sollen zuerst die SQL-Kommandos beschrieben werden, die nötig sind, um Proplets aus den einzelnen Tables zu rekonstruieren. Anschließend wird dargestellt, wie Proplets aus dem JLAG-System in die Datenbank eingefügt werden können. 7.2.1 Suchanfragen Verbproplets Das Kernstück für den Wiederaufbau eines Verbproplets bildet auf der Ebene der relationalen Algebra die Relation verbproplet“ (siehe 5.3.3). Ihre Umset” zung in SQL stellt sich folgendermaßen dar: SELECT verbproplet.prn AS prn, verbproplet.wdn AS wdn, verbproplet.concept AS concept, verbproplet.sur AS sur, actualverb.ctn AS ctn, actualverb.ctncnj AS ctncnj, nextverbproplet.concept AS ctnconcept, prevverb.prn AS ctp, prevverb.ctncnj AS ctpcnj, 55 FROM WHERE AND prevverbproplet.concept AS ctpconcept proplet verbproplet, verb actualverb LEFT OUTER JOIN verb nextverb ON actualverb.ctn = nextverb.prn LEFT OUTER JOIN proplet nextverbproplet ON nextverb.prn = nextverbproplet.prn LEFT OUTER JOIN verb prevverb ON prevverb.ctn = actualverb.prn LEFT OUTER JOIN proplet prevverbproplet ON prevverb.prn = prevverbproplet.prn verbproplet.prn = actualverb.prn verbproplet.wdn = actualverb.wdn; Die in der Entwicklung des relationalen Ausdrucks vorkommenden Teilterme ctnpartner und ctppartner sind im obigen SQL-Statement aufgegangen; sie finden sich in den Join-Bedingungen actualverb.ctn = nextverb.prn beziehungsweise actualverb.prn = prevverb.ctn prevverb.prn = preverbproplet.prn; wieder. Die zugehörigen Projektionen und Umbenennungen sind mit in die übergreifende SELECT-Klausel aufgenommen. Für jedes Verbproplet müssen jedoch zusätzlich noch die Werte für trc, arg, mdr, sem und cat ermittelt werden. Da dies jedoch nicht per Join geschieht, müssen für jedes aufzubauende Proplet einzelne Anfragen gestellt werden; diese beinhalten entsprechend der Ausdrücke in 5.3 WHERE-Klauseln, die die Tupel auf die zum aktuellen Proplet passenden restringieren. Das relevanten Traversionszählerattribut wird mit folgendem Statement ermittelt, bei dem die Fragezeichen den Platz der Werte von prn und wdn eines bestimmten Proplets einnehmen: SELECT timestamp FROM trc WHERE prn = ? AND wdn = ? ORDER BY timestamp; Durch die Sortierung per ORDER BY“-Klausel können die Resultatstupel di” rekt in die trc-Liste des Proplets aufgenommen werden. Der Ausdruck für die Bestimmung der Argumentliste stellt sich in SQL folgendermaßen dar: SELECT concept FROM proplet, WHERE noun.prn AND noun.prn AND noun.wdn ORDER BY argn; noun = ? = proplet.prn = proplet.wdn Auch hier wird eine Sortierung vorgenommen, um die einzelnen Argumente in der Reihenfolge auszugeben, in der sie auch im JLAG-Attribut arg auftauchen sollen. Bis auf diesen Zusatz geschieht die Berechnung der richtigen Werte für mdr analog: 56 SELECT FROM WHERE AND AND concept proplet, adverbial adverbial.prn = ? adverbial.prn = proplet.prn adverbial.wdn = proplet.wdn In beiden Fällen muss auch hier für das Fragezeichen der Wert von prn des jeweiligen Proplets eingesetzt werden. Um sem und cat wiederherstellen zu können, bedarf es der folgenden zwei, ähnlichen Anfragen: SELECT semcatn, semvalue FROM verbsem WHERE prn = ? ORDER BY semcatn, semn ; SELECT semcatn, catvalue FROM verbcat WHERE prn = ? ORDER BY semcatn, catn; Durch die Ordnung anhand des Attributs semn bzw. catn kann in der Projektion darauf verzichtet werden. Die eigentlichen Werte für sem und cat werden erst auf der höheren Ebene der programmiersprachlichen Einbettung in JLAG zusammengebaut. Diese werden dann anhand des Wertes von semcatn zusammengefasst. Nominalproplets Die Repräsentation der Relation nounproplet’ übernimmt folgendes SQL-Konstrukt, das als Basis für den weiteren Rekonstruktionsprozess von Nominalproplets dient: SELECT FROM WHERE AND AND AND AND nounproplet.prn AS prn, nounproplet.wdn AS wdn, nounproplet.concept AS concept,noun.idy AS idy, verbproplet.concept AS fnc proplet nounproplet, noun, proplet verbproplet, verb nounproplet.prn = noun.prn nounproplet.wdn = noun.wdn noun.prn = verb.prn verb.prn = verbproplet.prn verb.wdn = verbproplet.wdn; Das Resultat dieser Anfrage enthält also die Attribute prn, wdn, concept, idy und fnc. Es fehlen also wiederum trc, sem, cat und mdr. Der Traversionzähler wird ebenso wie bei Verbproplets rekonstruiert. Nur leichte Unterschiede ergeben sich bezüglich der Anfragen für die anderen drei Attribute: Es muss jeweils ein zusätzliches Attribut mit in der Selektion verarbeitet werden, da Nounproplets erst durch die Hinzunahme von wdn eindeutig identifiziert werden können. Außerdem unterscheiden sich natürlich die verwendeten Relationen. Die SQL-Statements stellen sich also folgendermaßen dar: SELECT semcatn, semvalue FROM nounsem WHERE prn = ? AND wdn = ? ORDER BY semcatn, semn; SELECT semcatn, catvalue 57 FROM nouncat WHERE prn = ? AND wdn = ? ORDER BY semcatn, catn: SELECT FROM WHERE AND AND AND concept proplet, adnominal adnominal.prn = ? adnominal.mddnoun = ? adnominal.prn = proplet.prn adnominal.wdn = proplet.wdn; Adverbialproplets Dem Ausdruck adverbialproplet’ entspricht das folgendes DML-Statement: SELECT FROM WHERE AND AND AND advproplet.prn AS prn, advproplet.wdn AS wdn, advproplet.concept AS concept, verbproplet.concept AS mdd proplet advproplet, adverbial, proplet verbproplet advproplet.prn = adverbial.prn advproplet.wdn = adverbial.wdn adverbial.prn = verbproplet.prn adverbial.wdn = verbproplet.wdn; Die drei separaten Anfragen für die restlichen zu rekonstruierenden Attribute werden mit SQL-Mitteln folgendermaßen dargestellt: SELECT semcatn, semvalue FROM advsem WHERE prn = ? AND wdn = ? ORDER BY semcatn, semn ; SELECT semcatn, catvalue FROM advcat WHERE prn = ? AND wdn = ? ORDER BY semcatn, catn ; Adnominalproplets Die Umsetzung des Terms adnominalproplet’ resultiert im folgenden SELECTStatement: SELECT FROM WHERE AND AND AND AND AND adnproplet.prn AS prn, adnproplet.wdn AS wdn, adnproplet.concept AS concept, noun.idy AS idy, nounproplet.concept AS mdd proplet adnproplet, adnominal, noun, proplet nounproplet adnproplet.prn = adnominal.prn adnproplet.wdn = adnominal.wdn adnominal.prn = noun.prn adnominal.mddNoun = noun.wdn noun.prn = nounproplet.prn noun.wdn = nounproplet.wdn; Die Anfragen für die fehlenden Attribute werden analog zu den anderen, bisher behandelten Proplettypen gebildet: 58 SELECT semcatn, semvalue FROM adnsem WHERE prn = ? AND wdn = ? ORDER BY semcatn, semn ; SELECT semcatn, catvalue FROM adncat WHERE prn = ? AND wdn = ? ORDER BY semcatn, catn ; Mit den gezeigten Anfragen können alle Attribute für die korrekte Präsentation in JLAG ausgegeben werden. Um spezielle Proplets gemäß der funktionalen Anforderungen zu erhalten, müssen die Statements für die Basisrelationen nounproplet’, verbproplet”, adnominalproplet und adverbialproplet um WHEREKlauseln erweitert werden.3 Darauf wird im nächsten Kapitel eingegangen. 3 Genau genommen werden natürlich AND-Klauseln hinzugefügt. 59 60 8 Benutzung der Datenbank in JLAG Um die Datenbank für JLAG nutzbar zu machen, bedarf es nun einer Integration in den Java-Code. Wie schon erwähnt geschieht dies über die Implementierung des Interfaces DBIF1 . Die einzelnen darin enthaltenen Methoden müssen ihrer Funktionalität entsprechend SQL-Kommandos an den Datenbank-Server absetzen und deren Ergebnisse für JLAG aufbereiten. 8.1 JDBC JDBC2 ist der bevorzugte Weg, um aus Java-Programmen heraus auf relationale Datenbanken zuzugreifen. In jedem JDK3 ist das dazu nötige Paket sql“ enthalten. Es stellt eine API4 zur Verfügung, mit der sich vollkommen ” Datenbanksystem-unabhängiger Code erzeugen lässt. Darüberhinaus ist allein ein passender JDBC-Treiber nötig, der die Java-Aufrufe für das spezielle System übersetzt. In der Implementierung im Rahmen dieser Arbeit wurde der offizielle MySQL-Treiber Connector/J in der Version 3.0.9 verwendet. 8.2 Algorithmus Die unterschiedliche logische Darstellung der Proplets in der Datenbank und JLAG erfordert einen teilweise ziemlich komplexen Abbildungsvorgang. Dies bedeutet natürlich nicht nur die Rekonstruktion der Merkmalstrukturen, sondern auch in der umgekehrten Richtung die Aufteilung der Informationen der JLAG-Proplets auf die verschiedenen Relationen. In den folgenden Unterabschnitten werden die dazu nötigen Algorithmen vorgestellt. 8.2.1 Einfügungen Wenn der Datenbank ein Proplet hinzugefügt werden soll, ist stets die Relation proplet“ betroffen; die nötigen Attributwerte für prn, wdn und con” cept können ohne weiteres der JLAG-Struktur entnommen werden. Genauso würden nun auch trc-Werte eingetragen, indem die Liste aus der Merkmalstruktur extrahiert und in einzelne Zeitmarkenwerte aufgeteilt würde. Jedoch ist dies momentan für das Einfügen irrelevant, da der Datenbank nur untraver1 siehe Kycia 2004 Das Akronym JDBC erinnert an Microsofts ODBC, was für Open DataBase Connectivity“ ” steht. Jedoch bestreiten die Entwickler, dass JDBC Java DataBase Connectivity“ bedeuten ” soll. Dennoch ähneln sich die beiden Produkte in ihrem Funktionalität. 3 Java development kit 4 application programming interface 2 61 sierte Proplets hinzugefügt werden. Die weiteren Schritte sind abhängig davon, welchem Typ ein Proplet angehört. • Bei Verben muss aus dem Wert von ctn die Nummer der nächsten Proposition und die möglicherweise vorhandene Konjunktion extrahiert werden. • Direkt im einzufügenden Nounproplet ist idy enthalten. Dagegen muss der Wert für argn mit Hilfe der Liste arg im zugehörigen Verbproplet berechnet werden. • Bei Adnominalen muss die Wortnummer des modifizierten Nounproplets ermittelt werden, um das Attribut mddnoun aufzufüllen. • Adverbiale erfordern keine speziellen Operationen. Darüberhinaus müssen die sem- und cat-Werte der JLAG-Proplets verarbeitet werden. Hier sind nur die betroffenen Relationen vom Typ abhängig, die einzufügenden Tupel besitzen einen identischen Aufbau. Zusammenfassend lässt sich der Einfügealgorithmus also folgendermaßen darstellen: FUEGE PROPLET EIN(Proplet neu) { NEUES TUPEL IN proplet (neu.prn, neu.wdn, neu.concept); proplettyp := ERMITTLE TYP(neu); WENN proplettyp = verb ctn := ERMITTLE CTN; ctncnj := ERMITTLE CTNCNJ; NEUES TUPEL IN verb (neu.prn, neu.wdn, ctn, ctncnj); WENN proplettyp = noun argn =:= ERMITTLE ARGN(neu.concept); NEUES TUPEL IN noun (neu.prn, neu.wdn, neu.idy, argn); WENN proplettyp = adnominal mddnoun := ERMITTLE WDN(neu.mdd); NEUES TUPEL IN adnominal (neu.prn, neu.wdn, mddnoun); WENN proplettyp = adverbial NEUES TUPEL IN adnominal (neu.prn, neu.wdn); semrel := ERMITTLE SEMRELATION(proplettyp); catrel := ERMITTLE CATRELATION(proplettyp); ZERLEGE neu.sem; FUER JEDEN SEMTEIL semcatn := ERMITTLE SEMTEILNUMMER; FUER JEDES UNTERELEMENT semn := ERMITTLE POSITION IN LISTE; NEUES TUPEL IN semrel (neu.prn, neu.wdn, semcatn, semvalue, semn); ZERLEGE neu.cat; FUER JEDEN CATTEIL semcatn := ERMITTLE CATTEILNUMMER; FUER JEDES UNTERELEMENT catn := ERMITTLE POSITION IN LISTE; NEUES TUPEL IN catrel (neu.prn, neu.wdn, semcatn, catvalue, catn); } 8.2.2 Anfragen Suchanfragen auf die Datenbank entstehen bei der Navigation, die durch den LA-Think gestartet wird. Hierfür sind Standardanfragen definiert, die durch zusätzliche Selektionen erweitert werden können. Diese entsprechen denen aus Kapitel 7.2. Zu Beginn eines jeden Denkprozesses wird stets eine Methode aufgerufen, die sämtliche Vorkommen eines bestimmten Verbkonzepts, seine sogenannte Tokenline, auflistet. 62 HOLE TOKENLINE(String konzept) anfrage := standardverbanfrage + SELEKTIONSBEDINGUNG(concept = konzept); STELLE ANFRAGE (anfrage); Dies soll bedeuten, dass an die Basisanfrage für Verben eine weitere ANDKlausel angehängt wird. Aus der resultierenden Liste wird von JLAG ein bestimmtes Proplet ausgewählt. Diese Entscheidung kann zufällig erfolgen oder auch anhand der Zahl der bisherigen Traversionen. Anfragen bei intrapropositionaler Navigation Soll nun die komplette Proposition rekonstruiert werden, müssen die restlichen Proplets ermittelt werden. Dazu dient im vorhandenen Java-Interface eine zweite Methode, die als Parameter ein Muster-Proplet erhält und folgendes Schema besitzt: HOLE PROPLET (Proplet muster) anfrage := standardanfrage + zusaetzliche restriktion; STELLE ANFRAGE (anfrage); Für Nounproplets enthalten die Anfragemuster die Attribute prn, fnc und noun: [prn: 1 ] [fnc: eat ] [noun: girl] Da im implementierten System nur ein Verb pro Proposition möglich ist, ist das Attribut fnc für diese Anfrage natürlich wiederum redundant, da seine Information schon in prn enthalten ist. Das bedeutet, dass die Basis-Nounanfrage erweitert werden muss, so dass sie sich folgendermaßen darstellt: anfrage := standardnounanfrage + SELEKTIONSBEDINGUNG (prn = muster.prn UND concept = muster.noun); Wenn anschließend Adnominale für das gefundene Nounproplet gesucht werden, sieht das Suchmuster ähnlich aus: [prn: 1 ] [idy: 1 ] [adj: big] Entsprechend muss das SQL-Statement aufgebaut sein: anfrage := standardadnominalanfrage + SELEKTIONSBEDINGUNG (prn = muster.prn UND idy = muster.idy UND concept = muster.adj); Zur Proposition gehörige Adverbiale können über folgende Anfrage ermittelt werden: anfrage := standardadverbialanfrage + SELEKTIONSBEDINGUNG (prn = muster.prn UND concept = muster.adj); 63 Anfragen bei extrapropositionaler Navigation Die extrapropositionalen Beziehungen können ebenfalls leicht über zusätzliche Selektionsbedingungen nachverfolgt werden. Soll ausgehend von einer Proposition die darauf folgende ermittelt werden, muss nur nach dem Verbproplet mit der Propositionsnummer gesucht werden, das dem aktuellen ctn-Wert entspricht. Für eine Anfrage genügt der Methode also ein Muster, das [prn: <aktueller ctn-wert> ] enthält. Damit wird die Anfrage also um nur eine zusätzliche Restriktionsklausesl erweitert. anfrage := standardverbanfrage + SELEKTIONSBEDINGUNG (prn = muster.prn); Rückwärtsnavigation lässt sich ähnlich abwickeln: Es wird das Proplet ermittelt, das in ctn den momentanen prn-Wert besitzt. [ctn: <aktueller prn-wert>] anfrage := standardverbanfrage + SELEKTIONSBEDINGUNG (ctn = muster.prn); Um alle Proplets zu ermitteln, die eine bestimmte Identität besitzen, genügt folgende Anfrage: anfrage := standardnounanfrage + SELEKTIONSBEDINGUNG (idy = muster.idy); 8.2.3 Löschungen Im zu implementierenden Interface gibt es eine einzige Methode, die Löschungen auf den Relationen vornimmt; diese setzt die gesamte Datenbank zurück, so dass für jede Table nur ein DELETE FROM“-Statement ohne weitere Re” striktionen ausgeführt werden muss. 8.2.4 Modifikationen Wenn Proplets bei der Navigation durch LA-Think verarbeitet werden, muss ihr Traversionszählerwert modifiziert werden. Vor allem hierfür existiert in der Datenbankenschnittstelle eine Methode, die die Werte der Attribute eines Proplets ändern kann. Als Übergabeparameter dient die komplette Merkmalstruktur mit den Werten, die in der Datenbank nach Abschluss der Operation enthalten sein sollen. Gleichzeitig dient diese zur Identifikation des zu bearbeitenden Proplets. Am einfachsten würden nun alle Relationen, die Tupel des entsprechenden Typs aufnehmen, mit den neuen Werten über UPDATE-Statements aktualisiert. Tatsächlich hat die entsprechende Methode updateWith(Proplet p) aber nur die Aufgabe, neue, die trc-Liste um einzelne Werte zu erweitern. Mit der vorliegenden Implementierung bedeutet dies also nur das Hinzufügen jeweils eines neuen Tupels in die Relation trc. 64 9 Zusammenfassung und Ausblick Das entwickelte Schema und die entsprechende Implementierung sollten allen Anforderungen genügen, die an eine Wortbank seitens des JLAG-Systems gestellt werden. Die zur Rekonstruktion der einzelnen Proplets nötigen SQL-Anweisungen sind zwar entsprechend der Menge der Relationen hinsichtlich des Codes teils recht lang, doch aus wenigen, einfachen Basiskonstrukten aufgebaut. Komplex sind allerdings teilweise die für den Im- und Export der Proplets nötigen Konvertierungen auf Java-Ebene; hierin zeigt sich, dass die JLAG-Strukturen von Natur aus nicht gerade perfekt mit relationalen Datenbanken harmonieren. Aber selbstverständlich können alle Informationen von der Datenbank aufgenommen und wiedergegeben werden. Die beschriebenen Konzepte sollten jederzeit auf andere relationale Datenbanksysteme anwendbar sein, auch weil auf möglichst SQL-konforme Implementierung geachtet wurde. Durch die vorhandenen Redundanzen in manchen Attributen der Proplets entstehen vor allem für Suchanfragen auf den Datenbestand zusätzliche Rekonstruktionsschritte, die jedoch aufgrund der besseren Lesbarkeit und des Einsatzzwecks des Systems gerechtfertigt sind. Da JLAG noch einen recht prototypischen Charakter besitzt, wurde bei der Entwicklung des konzeptionellen Schemas darauf geachtet, dass es auch auf zukünftige Anforderungen vorbereitet ist. Teilweise sind in den Relationen schon Attribute enthalten, aber auch Erweiterungen sollten ohne weiteres möglich sein. Ein verhältnismäßig großer Schritt wäre dabei die Einführung von Propositionen mit mehreren Verben. Doch auch dies würde hauptsächlich nur zur Hinzunahme des Attributes wdn“ zum Primärschlüssel der Relation verb“ ” ” und zum Anpassen der entsprechenden Fremdschlüssel führen. Auch die Anfragen würden modifiziert werden müssen, doch auch dies könnte nach Schema ” F“ abgewickelt werden. Unter Berücksichtigung der Möglichkeiten, die ein Datenbanksystem bietet, wäre dagegen eine Modifikation des Java-Interfaces denkbar. Zum Beispiel sollte die Funktionalität der Methode traverse“, die darin besteht, auf Basis einer ” Menge von aus der Datenbank extrahierten Proplets bestimmte herauszufiltern, idealerweise komplett vom Datenbanksystem übernommen werden: Über passenden Suchanfragen auf dem Datenbestand ist diese Aufgabe ohne weiteres zu lösen. Zur Zeit wird am Lehrstuhl für Computerlinguistik an der Universität ErlangenNürnberg von Martin Hampl eine Korpusdatenbank samt zugehöriger Anfragesprache entwickelt. Dabei stellt sich die Frage, inwiefern Zusammenhänge zwischen dieser und der im Rahmen dieser Arbeit erstellten Datenbank ergeben und wie diese eventuell zu einer Integration führen könnten. 65 Ein Korpus ist eine Sammlung von Texten in einer bestimmten Sprache, die als Grundlage für statistische Untersuchungen dienen soll. Somit stellt die Korpuslinguistik eine Art Grunddisziplin für andere Teilbereiche der Sprachwissenschaften dar. Abhängig vom Verwendungszweck des Korpus geschieht die Auswahl der Texte; um den Umfang einer Sprache umfassend zu erfassen, empfiehlt es sich, möglichst Ausschnitte aller Sprachgenres aufzunehmen. Im Brown-Korpus1 sind zum Beispiel 500 Texte aus 15 Genres wie PresseReportagen, Trivialliteratur, geistes- und naturwissenschaftliche Schriften enthalten. Die Aufgabe einer Korpusdatenbank ist es nun, sämtliche in den Texten enthaltenen Wörter zu speichern. Dabei ist nur die tatsächlich vorkommende Wortform, das Token, von Bedeutung, das heißt genau das, was im Kontext dieser Arbeit als Oberfläche bezeichnet wird. Hierin besteht ein Unterschied zur Wortbank: Da hier nicht auf Sprach- sondern auf Kontextebene operiert wird, sind Konzepte die zentralen Elemente. Daher erklärt sich auch ein zweites abweichendes Merkmal, nämlich, dass in Korpusdatenbanken für jede vorkommende Wortform der Eingabetexte Einträge vorgenommen werden. In einer Wortbank sind direkt nur Verben, Nomina und Adjektive enthalten; alle anderen Wörter wie zum Beispiel Artikel oder Hilfsverben sind in die entsprechenden Proplets mit hineincodiert. Interessant für Analysen auf einer fertigen Korpusdatenbank sind oftmals MetaInformationen wie zum Beispiel, in welchem Text und an welcher Stelle darin ein Token vorkommt, um auch speziellere Untersuchungen durchführen zu können. Daher könnte die Relation, die durch folgendes SQL-Statement beschrieben wird, das Kernstück bilden: create table token ( text_id integer not null, position integer not null, word VARCHAR(255), pos VARCHAR(255), primary key(text_id, position) ); Hiermit lassen sich nun Gemeinsamkeiten zu WURM aufzeigen: word“ nimmt ” die Wortform auf, was in der Wortbank sur“ entspricht. In pos“ ist die sprach” ” liche Kategorie eines Tokens gespeichert, zum Beispiel also Adjektiv“, Nomi” ” nalphrase“ etc. . Geht man nun davon aus, dass ein kognitiver Agenten denselben Eingabetext hört“, der der Korpusdatenbank zugrunde liegt, und in seiner Wortbank spei” chert, lässt sich jedem generierten Proplet ein Token der Korpusdatenbank zuordnen.2 Dies liese sich auf Fremdschlüsselbeziehungen zwischen Tupeln der Relationen proplet und token abbilden. Somit könnte dem Agenten auf einfache Art und Weise das Wissen darum vermittelt werden, in welchem Zusammenhang ein Wort, das durch ein bestimmtes Proplet repräsentiert wird, benutzt wurde: Das Wort Birne“ hat zum Beispiel in einem Artikel einer Zeitschrift ” für Elektrotechniker mit großer Sicherheit eine andere Bedeutung als in einem Kochrezept. Jedoch stellt sich die Frage, inwiefern eine solche Kombination der Datenbanken sinnvoll ist und ob diese Aufgabe nicht in einer eigenen Erweiterung der Wortbank besser aufgehoben wäre. Eine Korpusdatenbank unterscheidet sich hinsichtlich ihrer Funktion enorm von einer Wortbank: Sie ist stets nur ein Mittel zum Zwecke linguistischer Untersuchungen und stellt nicht wie WURM eine Art Gedächtnis dar. 1 Für amerikanisches Englisch 1967 von Kučera und Francis erstellt Theoretisch ließen sich mehrere zuordnen, nämlich nicht nur die Tokens, die Inhaltswörter repräsentieren, sondern auch die restlichen, die in den Attributen der Proplets implizit (bei Artikeln) oder explizit (im Falle von Konjunktionen) enthalten sind. Doch erscheint dies nicht sonderlich nützlich. 2 66 Literaturverzeichnis [Date 2000] Date, C. J. (2000): An Introduction to Database Systems. Reading, MA: Addison-Wesley. [Elmasri 2003] Elmasri, R., Navathe, Sh. (2003): Grundlagen von Datenbanksystemen. München: Pearson Studium. [Hausser 2000] Hausser, R. (2000): Grundlagen der Computerlinguistik. Berlin: Springer [Hausser DBS 2003] Hausser, R. (2003): Database Semantics for Natural Language Communication. Abteilung für Computerlinguistik, FriedrichAlexander-Universität Erlangen-Nürnberg [Hausser TT 2003] Hausser, R. (2003): Turn Taking in Database Semantics. Abteilung für Computerlinguistik, Friedrich-Alexander-Universität Erlangen-Nürnberg [Künneth 2001] Künneth, Th. (2001): Datenbankgestützte Speicherung von Korpora. Magisterarbeit, CLUE-Arbeitsberichte Nummer 4, Abteilung für Computerlinguistik, Friedrich-Alexander-Universität Erlangen-Nürnberg [Kycia 2004] Kycia, A. (2004) Implementierung der Datenbanksemantik in Java. Magisterarbeit in Bearbeitung, Abteilung für Computerlinguistik, Friedrich-Alexander-Universität Erlangen-Nürnberg [MySQL] MySQL Reference Manual. Dokumentation Datenbanksystems, erhältlich unter www.mysql.com des MySQL- 67