WURM - Eine Datenbank für die linguistischen Strukturen von JLAG

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 Universität
Erlangen wird erneut eine Arbeit aus dem Themenbereich Computerlinguistik
allen Interessierten zugänglich gemacht.
Die zugrunde liegende Studienarbeit von Wolfgang Fischer wurde 2002 am
Lehrstuhl für Informatik der FAU angenommen.
Dank gilt dem Autor, der die Quelltexte zur Verfügung stellte und Prof. Dr.
Roland Hausser für die finanziellen Mittel für den Druck.
Über den Autor
Wolfgang Fischer wurde 1979 in Nü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
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2
Anforderungen bezü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
Einfügeoperationen . . . . . . . . . . . . . . . . . . . .
10
3.5.2
Abfrageoperationen . . . . . . . . . . . . . . . . . . . .
10
3.5.3
Updateoperationen . . . . . . . . . . . . . . . . . . . .
11
3.5.4
Löschoperationen . . . . . . . . . . . . . . . . . . . . .
11
Konzeptioneller Entwurf
13
4.1
Entity-Relationship-Diagramme . . . . . . . . . . . . . . . . .
13
4.2
Die ER-Modellierung der Wortbank . . . . . . . . . . . . . . .
18
4.2.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2.2
Die Entitä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 Entitä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
Ü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
Löschungen . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.1.4
Einfü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
Einfügungen . . . . . . . . . . . . . . . . . . . . . . . .
61
8.2.2
Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . .
62
8.2.3
Löschungen . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.2.4
Modifikationen . . . . . . . . . . . . . . . . . . . . . . .
64
Zusammenfassung und Ausblick
65
Einleitung
1
Die Modellierung von natü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 können. In der Geschichte der
Linguistik finden sich mit Strukturalismus, Behaviourismus und Nativismus
Beispiele für Sprachtheorien1. Doch all diese Modelle berücksichtigen die Mechanik der natürlichen Sprache nicht, sondern kümmern sich nur um andere
Teilbereiche.
SLIM versucht, diese Lücke zu schließen; dieses Akronym steht für Surface
”
compositional Linear Internal Matching“. Dieses System chararkterisiert sich
folgendermaßen: Die Verarbeitung von Sprache wird funktional als Abgleich
( Matching“) von wörtlicher Sprachbedeutung und Verwendungskontext an”
gesehen. Dieser Abgleich geschieht streng oberflächenkompositional ( Surface
”
compositional“) und zeitlinear ( Linear“) als kognitiver Prozess innerhalb des
”
Sprecher/Hörers ( Internal“). Ein stark vereinfachtes Modell zeigt folgende Ab”
bildung.
Abbildung 1.1: Vereinfachtes
Sprachmodell von SLIM
Zeichenerkennung
Zeichensynthese
Sprachkomponente
Pragmatik
Kontextkomponente
Für den Nicht-Linguisten lässt sich der Kontext am besten als die Umwelt eines bestimmten Agenten zu einem bestimmten Zeitpunkt beschreiben. Sprache
dient dazu, Objekte des Kontexts ü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 Entitäten über Nominalphrasen (Symbole), Pronomina (Indexe) oder eben auch
Namen geschehen.
Genauso lassen sich die Bestandteile sprachlicher Äußerungen aber auch hinsichtlich der Hauptwortarten (Part Of Speech) unterscheiden: Dies sind Substantive, Verben und Adjektive. Da diese Differenzierung jedoch vollkommen
unabhängig von der der Zeichentypen besteht, lassen sich diesen Wortarten
auch Zeichentypen zuordnen.
Die gerade beschriebenen Elemente natürlicher Sprache lassen sich auf ihre
Grundform zurückführen, die als ihr Konzept bezeichnet wird. Wenn ein Agent
1
Darüberhinaus existieren natürlich noch viele weitere Systeme.
1
Abbildung 1.2:
Zeichenkategorisierung
Symbol
Index
Name
Nomen
Hund
dieser
Fido
Adjektiv
schwarz
hier
-
Verb
sehen
-
nun sprachliche Ä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 allgemeingültige Feststellungen treffen und somit als Basis fü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 mü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 ermöglichen, muss ihm ein Gedächtnis gegeben werden. Diese Wortbank genannte Datenbank muss die Propositionen aufnehmen und jederzeit zur Verfügung stellen
können.
Mit Database Semantics“ hat Professor Hausser eine Umsetzung von SLIM
”
vorgestellt. Die einzelnen Elemente der Propositionen werden als Merkmalstruktur modelliert und Proplet genannt. Sämtliche relevanten Informationen
werden in ihnen codiert.
Die sprachliche Komponente des in Abbildung 1.1 gezeigten Modells wird durch
eine LAG realisiert. LAG steht fü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 natürlichen Sprache einige Vorteile: Sie beruht auf dem Prinzip möglicher Fortsetzungen und bietet dadurch
eine niedrigere Komplexitä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 für JLAG zu realisieren, so dass
eine dauerhafte Speicherung und Wiederverwendbarkeit gewä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 nö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 genü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 zukünftigen Benutzern an die
Datenbank gestellt werden, genau untersucht, gesammelt und dokumen- tiert.
Hier ist besondere Sorgfalt vonnöten, da der gesamte weitere Entwurfsprozess
auf den Ergebnissen dieser Analyse beruht.
Als nä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 Verständigung mit dem oft fachfremden Auftraggeber ermöglichen
und als Basis für einen iterativen Verfeinerungsprozess dienen. Diese Phase wird
als konzeptionelles Design bezeichnet.
Anschließend wird im logischen Design die Entscheidung fü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 überfü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 erhält.
In den folgenden Kapiteln wird nach obigem Prozess eine Datenbank für linguistische Strukturen entwickelt. Zudem fü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 für alle weiteren Schritte gelegt
wird und somit grundlegende Fehler in dieser Phase die Qualität des Ergebnisses in hohem Grade negativ beeinflussen können.
Daher ist es nötig, mit großer Sorgfalt alle Anforderungen seitens der kü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 Einführung
Die beiden grundlegenden Begriffe der Database Semantics sind Proposition“
”
und Proplet“. Propositionen sind Mengen miteinander verknüpfter Proplets.
”
Die lexikalische Definition als Satz trifft im Rahmen dieser linguistischen Betrachtung nicht zu; eine Proposition besitzt nämlich immer nur ein Verb, wohingegen Sätze durchaus aus mehreren bestehen können, z.B. wenn einzelne
Teilsä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 Inhaltswörter Moritz“, klettert“, hohen“ und Baum“, die zweite er“, Vogel“
”
”
”
”
”
”
und gesehen“. Diese werden in Form von Merkmalstrukturen als Proplets dar”
gestellt.
Inhaltswörter sind also im Rahmen der natü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 kö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 gehören hingegen zur Gruppe der Funktionswörter. Sie besitzen
genau wie Negationen Operator-Charakteristik. Damit entsprechen sie extrapropositionalen Relationen, da sie Propositionen miteinander verknüpfen.
Die Unterteilung der Proplets in 18 verschiedene für Nomina, 12 für Adjektive und 6 für Verben2 ist für diese Arbeit von untergeordneter Bedeutung:
Die Unterscheidung der Zeichenarten Symbol, Index und Name ist nicht nötig,
da sie sich aus den Merkmalen der einzelnen Proplets ableiten lassen. Ob ein
sprachliches oder kontextuelles Proplet vorliegt, lässt sich in einem zusätzlichen
1
Gemäß des allgemeinen Charakters seiner wörtlichen Übersetzung als Hinzugeworfenes“
”
wird in der vorliegenden Arbeit Adjektiv“ als Oberbegriff für Adnominal und Adverbial
”
benutzt.
2 siehe DBS’03
5
Attribut codieren. Ebenso verhält es sich mit dem episodischen beziehungsweise
absoluten Charakter von Propositionen. Isolierte Proplets lassen sich ohnehin
einfach aus den ü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 bezüglich der Daten
3.2.1 Proplets
Proplets bilden das Fundament der Database Semantics. Als Merkmalstrukturen repräsentieren sie die Inhaltswö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 Oberfläche: Das gesprochene Wort“
”
• Ein Konzept: Eine Art Stammform der Oberfläche
• Eine oder mehrere Kategorien, die Eigenschaften für die syntaktische
Kombinatorik darstellen
• Eine oder mehrere semantische Werte, die jeweils zu genau einer Kategorie gehören
• Einen Traversionszähler, der aufnimmt, wann und wie oft bei der Navigation durch die gespeicherten Propositionen ein bestimmtes Proplet
abgefragt wurde
Kategorien sind elementare Eigenschaften von Wörtern, wie zum Beispiel Kasus, Numerus und Genus. Durch sie lässt sich bei der syntaktischen Analyse
Kompatibilität von einzelen Proplets feststellen. Zu den semantischen Werten
gehören einerseits Merkmale, die schon in den Kategorien enthalten sind, als
auch zusä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 Zusammengehörigkeit ein weiteres Attribut zugeordnet:
• Eine Propositionsnummer, die die Zugehö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 müssen sich natürlich in
der Datenbank wiederfinden.
3.2.3 Extrapropositionale Beziehungen
Verschiedene Nomenproplets können zueinander in einer Identitätsbeziehung
stehen: Die realweltliche Entität, die sie repräsentieren, ist die selbe.3
3
6
Dies ist natürlich auch innerhalb einer Proposition möglich.
Die wichtigsten extrapropositionalen Beziehungen stellen jedoch die Verknüpfungen zu den in der Folge direkt vorangegangen und nachfolgenden Propositionen
dar. Diese können sich in Konjunktionen wie und“ ausdrücken, jedoch können
”
auch Propositionen ohne diese Bindeglieder verknüpft sein, sofern sie zu einem
zusammenhängenden Textstück gehören.
Die Identität von Nominal-Proplets untereinander stellt den dritten Typ der
extrapropositionalen Verknü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 genügen, die die Basisgrammatiken der Database Semantics definieren:
LA-Hear produziert auf Basis von Eingabetexten neue Proplets, die in den
Datenbestand aufgenommen werden müssen. Wie der Name schon andeutet,
entspricht dieser Vorgang dem menschlichen Hö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 Funktionalität, die
durch die Schnittstelle bereitgestellt werden muss, umfasst:
• Navigation innerhalb von Propositionen: Die Wortbank muss Mittel bereitstellen, um einfach die zu einer Proposition gehörigen Proplets ansteuern zu können.
• Navigation zwischen benachbarten Propositionen: Es muss möglich sein,
einen Text über Beziehungen vorwärts und rückwärts zwischen Propositionen erzählen“ zu können.
”
• Direkter Zugriff auf bestimmte Konzepte: Da ein äußerer Reiz beim Agenten zum Gedanken an ein bestimmtes Konzept führen kann, muss die Datenbank die Möglichkeit bieten, effizient Proplets auszugeben, die ebendieses Konzept beinhalten.
• Direkter Zugriff über Identitäten: Um Inferenzen anwenden zu können,
ist es erforderlich, einfach mit Hilfe von Identitätsbeziehungen navigieren
zu können
• Modifikation von Traversionszählerwerten: Wenn an ein bestimmtes Proplet gedacht“ wurde, muss sein Traversionzä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 aufgeführten Bedürfnisse seitens der Anwendungswelt fü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 gehörige Oberfläche
cat
unter Umständen mehrere mögliche Kategorien
trc
möglicherweise mehrere semantische Kennzeichen-Kombination
Traversionszä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-Repräsentationen der Zeitpunkte der Traversion besteht
Integerwert
Der Tatsache, dass immer ein sem- und cat-Wert zusammengehören, wird durch
die Position der einzelnen Klammerausdrü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 frühzeitig in Hinblick
auf die Speicherung in der Datenbank eingeführt. Für jedes neue Proplet einer Proposition wird ein Zahlenwert vergeben, so dass durch Kombination von
prn“ und wrdn“ eine eindeutige Indentifizierung gewä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 mögliches Verbproplet.
Die zusätzlichen Attribute erklä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 nä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 Oberfläche
der Konjunktion am Ende des
Vektors
Die Reihenfolge der einzelnen Argumente in arg ist relevant, da sie die Kasus der einzelnen Nomina reprä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
Identitä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
Identitätsverweis
mdd
idy
Zeichenkette, die die Oberfläche
des Modifikanden darstellt
Integerwert, der natürlich nur im
Falle von adnominaler Verwendung angibt, welche Identitätsnummer das zugehö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 für die Kommunikation zwischen JLAG und dem Datenbanksystem dar. Ein Teil der darin spezifizierten Methoden bringt tatsächliche
Datenbankzugriffe mit sich; die Mehrheit jedoch operiert entweder auf temporä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 Einfügeoperationen
In DBIF sind drei Methoden enthalten, die direkt Einfügungen mit sich bringen.
Dies sind im Einzelnen:
• add(Proplet p): Hinzufügen eines einzelnen Objekts der JLAG-Klasse
Proplet
• add(List pList): Hinzufügen eines Listen-Objekts, bestehend aus Proplets
• add(Proplet[] pArray): Hinzufügen eines Arrays von Proplet-Objekten
Die Funktion aller add-Varianten besteht somit im Einfügen neuer Proplets in
die Wortbank. Alle drei lassen sich auf eine einzige zurückführen; in der Implementierung namens Wordbank von Arkadius Kycia ist die Hauptfunktionalitä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 ü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 Fällen mü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 übergeben.5
3.5.3 Updateoperationen
Die einzige Methode, die nach JLAG-Verständnis bestehende Proplets modifiziert ist
• updateWith(Proplet p)
Zwar lässt ihr Name eine allgemeine Verwendbarkeit vermuten, jedoch beschrä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 Traversionszählerwert um einen Zeitstempel
verlängert“ werden muss.
”
Durch das Parameter-Proplet wird sowohl die zu modifizierende Instanz identifiziert, als auch der neue Wert von trc übergeben. Beispielsweise muss bei
Ü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 über die Kombination von prn und wrdn gefunden werden und anschließend der höchste Einzelwert aus der trc-Liste in die
Wortbank eingetragen werden.
3.5.4 Löschoperationen
Im Rahmen der normalen Betriebsart“ des JLAG-Systems als kognitiver Agent
”
sind keine Löschungen zu beachten. Jedoch existiert mit
• resetWordbank()
eine Methode, mit der die gesamte Wortbank gelöscht werden können muss.
Dies bedeutet nichts anderes als die Entfernung sämtlicher Proplets. Jedoch ist
das selbstverstä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
für die Diskussion mit dem Auftraggeber und für die weitere Entwicklung zu
schaffen. Dies sollte natürlich in einer leicht lesbaren und verstä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 für Unified Modelling Language. Diese graphische
Sprache bietet ein weites Spektrum an Möglichkeiten, die weit über das für
die Modellierung einer Datenbank Nötige hinausgehen; diese Vielfalt erschwert
jedoch die intuitive Lesbarkeit.
Gerade im Bereich der Datenbanken wird oft auf Entity-Relationship-Diagramme
zurückgegriffen. Diese bieten eine relativ kompakte Syntax, die auch aufgrund
der verwendeten Symbolik von vielen als leichter verständlich betrachtet wird.
Dennoch wird ein hohes Maß an konstruktiver Mächtigkeit geboten. Daher soll
die Modellierung der linguistischen Strukturen auf dieser abstrakten Ebene mit
Hilfe eines ERD erfolgen.
Im folgenden soll eine kurze Einführung in diese Technik gegeben werden; jedoch beschränkt sie sich weitestgehend auf die für die vorliegende Arbeit relevanten Elemente.
Entity-Relationship-Diagramme bestehen grundsätzlich aus drei Bestandteilen:
Entitätstypen, Attributen und Relationshiptypen.
Entitätstypen repräsentieren Mengen von Entitäten, die dieselben Attribute
besitzen. Entitäten wiederum sind Dinge der realen Welt, die eine physische
oder konzeptionelle Existenz besitzen. Ein klassisches Beispiel für einen Entitätstypen ist Auto“; jede einzelne Entität, das heißt jede spezielle Instanz
”
dieses Typs, hat die gleichen Attribute, z.B. Hersteller, Modellname, Farbe.
Die Beziehung zwischen Entitätstyp und Entität ist ähnlich der zwischen Klasse und Objekt, wie man es aus der objektorientierten Programmierung kennt.
In der Welt der Linguistik bekannter dürfte jedoch das korrespondierende Begriffspaar Type-Token sein.
In einem ERD werden Entitätstypen als Rechtecke dargestellt; für die zugehörigen Attribute werden Ellipsen gezeichnet und diese über ungerichtete Kanten
mit dem Entitätsyp verbunden.
Die in der obigen Abbildung vorkommenden Attribute sind sogenannte einfache
Attribute. Darüberhinaus existieren jedoch auch komplexe:
Mehrwertige Attribute sind solche, bei denen der Wert bezüglich einer Entität
13
Abbildung 4.1: Der Entitätstyp
Auto
Auto
Modellname
Farbe
Hersteller
Abbildung 4.2: Ein mehrwertiges
Attribut
Person
Telephon
eine Menge darstellt. Ein Beispiel wäre eine Entitä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 fü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 zusätzlich als mehrwertiges kennzeichnen:
Relationships sind Beziehungen zwischen Entitäten; Relationshiptypen stellen
Mengen solcher gleichartiger Beziehungen dar. Diese werden in einem ERD als
Rauten gezeichnet und werden via ungerichteter Kanten mit den beteiligten
Entitätstypen verbunden.
Jeder Relationshiptyp besitzt ein Kardinalitätsverhältnis, das ausdrückt, wie
viele Entitä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 für diese drei Typen wären
Beziehungen mit den Namen ist-verheiratet“ zwischen einer Mann- und einer
”
Frau-Entität (1:1), Vater-von“ zwischen einer Mann- und n Kind-Entitäten
”
(1:n) und war-verheiratet“ zwischen m Mann- und n Frau-Entitäten. Die Kar”
14
Abbildung 4.4: Ein
zusammengesetztes,
mehrwertiges Attribut
Person
Anschrift
Straße
Ort
dinalitä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 Entitätstyp total partizipiert, bedeutet
dies, dass jeder einzelnen Entität eine oder mehrere Entitäten (je nach Kardinalität) auf der Gegenseite zugeordnet sind. Dementsprechend bedeutet partielle
Partizipation, dass eine Entität nicht zwangsläufig zu einer Entität des anderen
Typs in Beziehung stehen muss.
Beispielsweise würde der Entitä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 Entitätstypen können Attribute besitzen; diese werden ebenso wie bei
den Relationshiptypen als Ellipsen dargestellt und ü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 Entitätstypen
Fahrzeug“ und LKW“/ PKW“ vor und wird folgendermaßen dargestellt.
”
”
”
Eine mö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 Entitäten
der einzelnen, abgeleiteten Typen zueinander verhalten: Entweder disjunkt oder
überlappend. Ersteres bedeutet, dass eine Entität immer nur einem spezialisierten Typ angehören kann. Im zweiten Fall sind auch mehrere Vorkommen erlaubt. Gemäß der englischen Ü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 Entitätstypen
gekennzeichnet.
Außerdem lassen sich Spezialisierungen in totale und partielle Spezialisierungen
unterteilen; im totalen Fall muss jede Entität eines Basistyps einem abgeleiteten Typ angehören, im partiellen Fall hingegen nicht. Die Darstellung erfolgt
mit doppelten Kanten für totale und einfachen Kanten für partielle Spezialisierungen (analog zur Partizipation bei Relationshiptypen).
Die folgenden Abbildung zeigt ein einfaches Beispiel einer totalen Spezialisierung mit disjunkt-Einschränkung:
Abbildung 4.8: Totale, disjunkte
Spezialisierung
Mensch
d
Mann
Frau
In natü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-Einschränkung.
16
Damit ist die Beschreibung der fü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 Einführung
Die Modellierung der linguistischen Strukturen mit dem Ziel, eine vor allem redundanzfreie und effiziente Speicherung in einer Datenbank zu erreichen, bringt
einige Unterschiede gegenü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-Entitätstypen Verb, Noun, Adnominal und Adverbial. Jedoch existiert eine Menge an Attributen, die allen
genannten Typen gemeinsam ist. Dieser Umstand findet sich natü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 Gründen der Les- und Nachvollziehbarkeit. Da die
Datenbank jedoch unter diesem Überbau verborgen bleibt, ist eine effiziente,
redundanzfreie Speicherung von höchster Priorität. Effektiv bedeutet das, dass
sich Attribute, wie sie in einem Proplet auf JLAG-Ebene auftauchen, nicht
immer direkt im entsprechenden ERD oder im später daraus entwickelten Relationenschema widerspiegeln. Die für die Rekonstruktion eines JLAG-Proplets
notwendigen Informationen besteht somit in vielen Fällen in der Benutzung der
Beziehungen zu anderen Proplets.
Wenn man von Attributen eines bestimmten Proplets spricht, kö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 Entitätstypen
Proplet
Der Entitä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 gehört zu jedem Proplet ein Traversionszä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 Entitätstypen eingeführt
und mit den relevanten Attributen versehen werden.
18
Abbildung 4.9: Der Entitä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 Entitä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, begrü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 Begrü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 zugehörige Verb bestimmen lässt, episodischen oder absoluten
Charakter besitzt.
Das Atribut lang“ gibt Auskunft darüber, ob es sich um eine Proposition auf
”
Sprach- oder Kontextebene handelt.
Gemäß der Anforderungen besteht eine Verknüpfung zwischen einem Verbproplet und demjenigen der nächsten Proposition, was in einem JLAG-Verbproplet
durch das Attribut ctn“ dargestellt wird. Dieser Umstand ist im ERD als 1:1”
Beziehung zwischen Verb-Entitä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 lä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-Entitäts19
Abbildung 4.11: Der Entitä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-Entität steht in
”
einem Funktor-Argument-Verhältnis zu n Nounproplet-Entitäten (aber immer
mindestens einem, so dass an dieser Stelle totale Partizipation vorliegt.). Da
die Reihenfolge der Argumente jedoch aufgrund der verschiedenen Funktionalitä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 Entitä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-Entitätstypen Adverbial“ und Noun“ erläutert.
”
”
Adverbial
Der Entitätstyp Adverbial besitzt das schon oben beschriebene Attribut sem”
cat“, das aus den Teilen sem“ und cat“ besteht und Multicats ermöglicht.
”
”
Ansonsten sind die Werte aller Attribute, die ein Proplet mit adverbialer Funktionalität auf der Ebene des JLAG-Systems besitzt, entweder schon im Basistyp
Proplet enthalten oder durch die Beziehung zu einer Verbentität ermittelbar.
Abbildung 4.12: Der Entitätstyp
Adverbial
sem
cat
semcat
Adverbial
Noun
Der Entitätstyp Noun“ repräsentiert die Proplets, die Nomina aufnehmen.
”
Natürlich besitzt auch er das mehrwertige Attribut semcat.
Nounentitäten können untereinander in einer Identitätsbeziehung stehen. Dem20
zufolge besteht ein rekursiver Relationshiptyp1 . Das Kardinalitätsverhältnis ist
m:n, da jedem Proplet mehrere andere mit derselben Identität gegenüberstehen
können.
Die Funktor-Argument-Beziehung eines Nouns zu einem Verb, die in einem
JLAG-Verbproplet durch das Attribut fnc“ repräsentiert wird, wurde schon
”
bei der Beschreibung des Entitä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 Entitä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 Entitä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 Möglichkeit zur
Darstellung des konzeptionellen Schemas. Seine Entwicklung hatte wohl den
größ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 jüngster Zeit aufgewertet und werden so auch den
Anforderungen der modernen Softwarewelt gerecht.
Wie der Name schon vermuten lässt stellt der Begriff Relation“ den Kernpunkt
”
des relationalen Modells dar, das sich intuitiv anhand dreier Gesichtspunkte1
charakterisieren lässt:
• Struktureller Aspekt: Alle Daten einer Datenbank sind in Relationen gespeichert, die sich dem Benutzer als Tabellen darstellen.
• Diese Tabellen unterliegen bestimmten Integritätsbestimmungen, die eingehalten werden mü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 zugehörigen Domä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 Kardinalität genannt.
Eine Datenbank besteht aus einer Menge solcher Relationen, genauer gesagt
aus einer Menge von Relationenschemata samt der zugehörigen Tupel.
Formal definiert stellt eine Relation eine Untermenge des kartesischen Produktes aus einer Menge von Werten bestimmter Domä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 Domänen
stets nur primitive Datentypen darstellen, also nicht unterstrukturierte Werte
wie Mengen oder Listen aufnehmen.
Ein wichtiges Konzept des Modells ist der Schlüssel: Ein Schlü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 möglicherweise mehrere Kandidaten gibt, muss für jede Relation einer ausgewählt werden, der dann als Primärschlüssel bezeichnet wird.
Wenn extra ein Attribut als Primärschlüssel eingeführt wird, spricht man auf
englisch von einem surrogate key“.
”
Über sogenannte Fremdschlüssel lassen sich Tupel auch über Relationen hinweg
referenzieren. Fremdschlüssel stellen Attribute dar, deren Werte mit denen der
Primärschlüssel von Tupeln der referierten Relation übereinstimmen müssen
oder NULL sind. Dieser Umstand wird als referentielle Integrität bezeichnet.
Ein System, das das relationale Modell implementiert, muss diese unbedingt
gewährleisten.
Darüber hinaus lässt das relationale Modell weitere Integritätsbestimmungen
zu, die von Benutzer definiert werden können. Sie stellen Regeln aus der Anwendungswelt dar. Ihre Einhaltung muss vom Datenbanksystem gewä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 für den Datenbankgebrauch entwickelten Operatoren: Die Projektion, die Selektion, der Join und die Division. Im Folgenden
sollen sie jeweils kurz erläutert werden.
Projektion
Mit Hilfe der Projektion werden Attribute ausgewä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 Umständen nicht nur der Grad, sondern auch die
Kardinalität einer Relation, wie obiges Beispiel zeigt. Dies begründet sich darin,
dass es keine zwei identischen Tupel geben darf. Dazu kann es jedoch kommen,
wenn die Attributliste der Projektion keinen Schlüssel der Ausgangsrelation
beinhaltet. Deshalb müssen die Tupel mit gleichen Werten auf einen einzigen
reduziert werden.
Selektion
Dieser auch als Restriktion bezeichnete Operator dient dazu, Tupel einer Relation auszuwählen. Dazu dient eine bestimmte Auswahlbedingung. In der Resultatsrelation sind nur diejenigen Tupel enthalten die dieser Bedingung genügen.
Das Ergebnis einer Selektion
R2 = SEL[bedingung]R1
besitzt also möglicherweise eine geringere Kardinaltität als die Ursprungsrelation:
Kardinalität(R2 ) ≤ Kardinalität(R1 )
Der Grad hingegen bleibt stets konstant. Selektionsbedingungen bestehen aus
Elementareinheiten, die auch über boolesche Verknüpfungen zu komplexen Bedingungen konstruiert werden kö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 lä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 Fremdschlü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 Kardinalität lässt sich durch
Kardinalität(R3 ) = Kardinalität(R1 ) ∗ Kardinalitä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 für Datenbanken ergibt sich erst im Kontext des Join-Operators; durch die zugehö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 lässt als Vergleichsoperation nur den Test auf
Gleichheit zu. Darauf aufbauend bietet der sogenannte Natural-Join zusä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 zusä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
natürlich nicht für alle Attribute Werte besitzen, werden diese mit null“ auf”
gefüllt. Der Outer-Join existiert in drei Varianten: Der Left-Outer-Join nimmt
nur partnerlose Tupel der links vom Operator stehenden Relation zusätzlich
auf, der Right-Outer-Join nur die der rechten. Mit Full-Outer-Joins werden
beide Seiten berücksichtigt, so dass kein Tupel verloren geht“.
”
Diese Join-Variante ist vor allem dann nützlich, wenn bestimmte Tupel zu anderen in einer optionalen Teil-Ganzes-Beziehung stehen. Basierend auf den oben
benutzten Relationen könnte man sich zum Beispiel eine Anfrage vorstellen,
die alle Personen und - falls vorhanden - ihre Telephonnummern ausgeben soll.
Mit einem konventionellen Join wü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 fü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 übereinstimmen, abzüglich
eben dieser Attribute.
Oder anders ausgedrü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
Zusätzlich zu den beschriebenen Operatoren erweist sich ein weiterer aus Gründen
der Übersichtlichkeit und Verständlichkeit als nützlich: Die Umbenennung. Daher wird sie unter der Bezeichnung REN“ (für rename“) folgendermaßen ein”
”
geführt: Mit der Ausgangsrelation
R1 (a1 , a2 , a3 )
2
Oder ohne bekannte Nummer. Hier zeigt sich die Mö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 müssen aber nicht beide Teile neu festgelegt
werden.
Da die Mengenoperationen als bekannt vorausgesetzt werden dürfen, ist an dieser Stelle die Einführung in das relationale Modell abgeschlossen. Das nä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 kö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 Möglichkeiten der Umsetzung existieren. Daher hat der Designer gewisse Freiheitsgrade, was eine Optimierung der Datenbank hinsichtlich der Anwendungswelt ermöglicht. Im Folgenden soll beschrieben werden, wie das oben
entwickelte Entity-Relationship-Diagramm auf Relationen abgebildet wurde.
Es werden deshalb nur die für diese spezielle Umgebung nötigen MappingSchritte dargestellt.
5.2.1 Abbilden der Entitätstypen
Als erstes wird für jeden vorkommenden Entitätstypen direkt jeweils eine Relation geschaffen, die alle einfachen Attribute enthält. Das Mapping von Proplet3
führt zum Beispiel zur folgenden Relation:
Abbildung 5.7: Die Relation
proplet
proplet
( prn, wdn, sur, concept )
Primärschlüssel: (prn,wdn)
Gleichzeitig wird ein Primärschlüssel gewählt, der ein Tupel der jeweiligen Relation eindeutig identifiziert. Im Falle von proplet ist dieser aus den Attributen
prn und wdn zusammengesetzt.
Sämtliche anderen Entitätstypen sind von Proplet abgeleitet; dieser Umstand
wird dadurch abgebildet, dass jeder dieser Typen den Primärschlüssel der Relation proplet als Fremdschlüssel als weiteres Attribut (bzw. als weitere Attribute, wenn der Schlüssel zusammengesetzt ist) erhält. Es entstehen also folgende
Relationen:
Abbildung 5.8: Die Relationen
der spezialisierten Typen
adnominal
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
noun
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
verb
( prn, wdn, lang, epi )
Primärschlüssel: (prn)
Fremdschlüssel: (prn,wdn) referenziert proplet
adverb
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
Die beiden Relationen noun, adnominal und adverb besitzen in diesem Stadium
des Mappings noch keine weiteren, speziellen Attribute; dies ändert sich jedoch
im weiteren Verlauf.
Eine Besonderheit stellt die Relation verb dar: Hier wird nicht wie in den anderen angeführten Fällen ein aus prn und wdn zusammengesetzter Primärschlüssel
benötigt. Das Attribut prn allein genügt, da eine Proposition stets nur ein Verb
beinhalten kann.
3
siehe 4.9
29
5.2.2 Abbilden der Relationshiptypen
Die nä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-Entitäten
namens ctn.
Die zweckmäßige Umsetzung besteht darin, die Relation verb um ein Attribut
zu erweitern, das den Primärschlüssel des über ctn referenzierten Tupels als
Fremdschlüssel aufnimmt.
Der Relationshiptyp ctn besitzt jedoch ein eigenes Attribut namens ctncnj,
das natürlich auch im relationalen Schema berücksichtigt werden muss. Dies
geschieht, indem man dieses Attribut ebenfalls der Relation verb hinzufügt:
Abbildung 5.9: Die Relation verb
mit Fremdschlüsselattribut ctn
verb
( prn, wdn, lang, epi, ctn, ctncnj )
Primärschlüssel: (prn)
Fremdschlüssel: (ctn) referenziert verb
Nun werden die 1:n-Relationshiptypen umgesetzt; die lehrbuchmäßige Lösung
sieht vor, die Relation auf der n-Seite der Beziehungsmenge um ein Fremdschlü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 Primärschlüssel prn besitzt. Die Information, die ein zusätzliches Fremdschlüsselattribut in noun beziehungsweise adverb aufnehmen wü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 zusätzliche Fremdschlüsselattribute verzichtet werden.
Ähnlich verhä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 hinzugefügt werden, da
der Primärschlüssel von noun nicht nur aus prn, sondern zusätzlich aus wdn
besteht. Dieses neue Attribut wird mit mddnoun bezeichnet, was für modified
”
noun“ steht.
Wie schon ctn ist auch dem Beziehungstyp arg ein Attribut zugeordnet, das
in analoger Weise der Relation, die den Fremdschlüssel aufnimmt (also noun),
hinzugefügt wird.
Abbildung 5.10: Die Relationen
nach dem Mapping der
Relationshiptypen
adnominal
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
Fremdschlüssel: (prn, mddnoun) referenziert noun
noun
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
Fremdschlüssel: (prn) referenziert verb
adverbial
( prn, wdn )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
Fremdschlüssel: (prn) referenziert verb
Der einzige Beziehungstyp mit dem Kardinalitätsverhältnis m:n im Diagramm
ist derjenige namens idy: Er bildet die Identität zwischen Nomina ab und verbindet somit noun-Tupel mit untereinander. Normalerweise führt man zur Abbildung von m:n-Relationshiptypen Kardinalitäten eine zusätzliche Relation
ein, die die Primärschlüssel der an diesem Beziehungstyp beteiligten Relationen
30
als Fremdschlüsselattribute aufnimmt. Da idy jedoch rekursiv noun-Entitäten
verknüpft, empfiehlt sich eine andere Lösung, durch die der hohe Wartungs- und
Abfrageaufwand, den die Variante mit Zusatzrelation mit sich bringen würde,
vermieden werden kann: Die Relation noun wird um ein Attribut namens idy
erweitert, das eine Identitätsnummer darstellt. Durch Restriktion in einer Anfrage kann dann leicht ermittelt werden, welche Nouns dieselbe realweltliche
Entität darstellen.
Das Mapping der Beziehungstypen fü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 Entitätstyp Proplet gehört. Zu seiner Umsetzung wird eine zusätzliche Relation angelegt, die einzelne Traversionszählerwerte (d.h. Zeitstempel) aufnimmt und per Fremdschlüsselbeziehung
das zugehörige Tupel in proplet referenziert:
Abbildung 5.11: Die Relation trc
trc
( prn, wdn, timestamp )
Primärschlüssel: (*)
Fremdschlüssel: (prn, wdn) referenziert proplet
Dies entspricht der klassischen Abbildung von mehrwertigen Attributen und ist
hier vollkommen angemessen. Anders wurden hingegen in den restlichen Fällen
verfahren. Die entsprechenden Attribute sind jeweils als semcat“ benannt und
”
unterscheiden sich auf ERD-Ebene nur durch ihre Entitätstyp-Zugehörigkeit.
Dementsprechend erfolgt ihr Mapping analog.
Semcat setzt sich aus den sem und cat zusammen. Bei näherer Betrachtung der
Werte dieser beiden Attribute im JLAG-System stellt man fest, dass ihre Werte
komplexe Zeichenketten darstellen können. Insofern ist eine 1:1-Übernahme in
das Relationenmodell nicht empfehlenswert. Eine Lösung besteht darin, die
Werte als Listen von Elementarbausteinen zu betrachten. Dies soll am Beispiel
von noun erläutert werden: Zwei Relationen nounsem und nouncat werden
eingeführt und mit folgenden Attributen versehen: Einem Fremdschlüssel, der
das zugehö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 für nounsem:
Abbildung 5.12: Die Relation
nounsem provisorisch
nounsem
( prn, wdn, semvalue, semn )
Primärschlüssel: (*)
Fremdschlüssel: (prn, wdn) referenziert noun
semvalue“ ist der Name des Attibuts fü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 gelöst, indem man ein
weiteres Attribut einführt, das die Zugehörigkeit zu einem bestimmten semcatPaar kennzeichnet.
Hier wäre auch eine alternative, mehrstufige4 Abbildung möglich, die zwar
dem Diagramm näher stehen wü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 für die anderen Proplet-Untertypen angewendet.
Wiederum ist natürlich im Falle der Relation verb die Besonderheit zu beachten, dass deren Primärschlüssel nur aus prn besteht.
4
Die gewählte Variante schafft die Zwischenstufe semcat“ ab.
”
31
Abbildung 5.13: Die Relationen
nounsem und nouncat
nounsem
( prn, wdn, semcatn, semvalue, semn )
Primärschlüssel: (*)
Fremdschlüssel: (prn, wdn) referenziert noun
nouncat
( prn, wdn, semcatn, catvalue, catn )
Primärschlüssel: (*)
Fremdschlü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 )
Primärschlüssel: (prn,wdn)
Attribute:
prn:
wdn:
sur:
concept:
trc
( prn, wdn, timestamp )
Primärschlüssel: (*)
Fremdschlüssel: (prn, wdn) referenziert proplet
Attribute:
timestamp:
adnominal
Zeitmarke, zu der ein Proplet zuletzt traversiert wurde
Ganzzahlwert
( prn, wdn, mddnoun )
Primärschlüssel: (prn,wdn)
Fremdschlüssel: (prn,wdn) referenziert proplet
Fremdschlüssel: (prn, mddnoun) referenziert noun
Attribute:
mddnoun:
adnsem
Nummer der Proposition, der das Proplet angehört;
Ganzzahlwert
Laufende Nummer des Wortes innerhalb der Proposition;
Kleiner Ganzzahlwert
Oberfläche der Wortform;
Zeichenkette
Der Wortform zugrundeliegendes Konzept;
Zeichenkette
Die Nummer des modifizierten Wortes in der Proposition
Ganzzahlwert (wdn entsprechend, da Fremdschlüssel)
( prn, wdn, semcatn, semvalue, semn )
Primärschlüssel: ( prn, wdn, semcatn, semn )
Fremdschlü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 )
Primärschlüssel: ( prn, wdn, semcatn, catn )
Fremdschlüssel: ( prn, wdn ) referenziert adnominal
Attribute:
catvalue:
catN:
noun
( prn, wdn, idy, argn )
Primärschlüssel: ( prn, wdn )
Fremdschlüssel: ( prn, wdn ) referenziert proplet
Fremdschlü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 )
Primärschlüssel: ( prn )
Fremdschlüssel: ( prn, wdn ) referenziert proplet
Fremdschlü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 )
Primärschlüssel: ( prn, wdn, semcatn, catn )
Fremdschlüssel: ( prn, wdn ) referenziert noun
Attribute:
catvalue:
verb
Zur Abbildung von Identitäten zwischen Nouns;
Ganzzahlwert
Nummer eines Noun in der Arg-Liste des zugehörigen
Verbs;
Kleiner Ganzzahlwert
( prn, wdn, semcatn, semvalue, semn )
Primärschlüssel: ( prn, wdn, semcatn, semn )
Fremdschlü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 zugehörige Proposition episodisch oder absolut?
Boolesch
Ist die zugehörige Proposition auf Sprach- oder Kontextebene?
Boolesch
Verweis auf die nächste Proposition bzw. das nächste
Verb-Proplet;
Ganzzahlwert (prn entsprechend, da Fremdschlüssel)
Konjunktion, die Proposition mit der nächsten verbindet, auch leer möglich;
Zeichenkette
verbsem
( prn, semcatn, semvalue, semn )
Primärschlüssel: ( prn, semcatn, semn )
Fremdschlü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 )
Primärschlüssel: ( prn, semcatn, catn )
Fremdschlü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 )
Primärschlüssel: ( prn, wdn )
Fremdschlüssel: ( prn, wdn ) referenziert proplet
Fremdschlüssel: ( prn ) referenziert verb
advsem
( prn, wdn, semcatn, semvalue, semn )
Primärschlüssel: ( prn, wdn, semcatn, semn )
Fremdschlüssel: ( prn, wdn ) referenziert adverbial
Attribute:
semvalue:
advcat
Zeichenkette aus { stand“, comp“, sup“}
”
”
”
( prn, wdn, semcatn, catvalue, catn )
Primärschlüssel: ( prn, wdn, semcatn, catn )
Fremdschlüssel: ( prn, wdn ) referenziert adverbial
Attribute:
catvalue:
Zeichenkette aus { ADV“}
”
35
5.2.5 Überblick
Zur Verdeutlichung soll nun ein Überblick gegeben werden, wie die Attribute
von JLAG und die der Datenbank zusammenhängen. Dabei wird zur Identifikation eine Punktnotation mit der Bedeutung relationenname.attributname
benutzt. Besitzt ein JLAG-Attribut aus Gründen der Redundanzfreiheit kein
entsprechendes Pendant in den Tupeln des eigentlichen Proplets und muss über
Fremdschlüssel ermittelt werden, werden diese indirekt benutzten Attribute
durch Klammern eingeschlossen.
Um ein gewisses Maß an Übersichtlickeit zu gewährleisten, soll an dieser Stelle
stets auf die explizite Nennung von Fremdschlü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 nötig. Diese hä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 lässt sich über
Fremdschlü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 zugehörigen Tupel von noun, bei
Adnominal-Proplets im zugehö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 können nun Kombinationen von relationalen
Operatoren angewendet werden, so dass sich die Informationen entsprechend
der funktionalen Anforderungen extrahieren lassen. Im folgenden sollen Ausdrücke der relationalen Algebra fü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 Möglichkeiten: Die beiden Extreme sind
der Join aller nötigen Relationen einerseits , so dass sich alle nötigen Informationen zur Rekonstruktion einer JLAG-Merkmalstruktur in einer einzigen
Relation finden lassen, und die separate Abfrage auf höchster Ebene andererseits. Bei der letzten Variante muss sozusagen eine Art Join außerhalb eines
Datenbanksystems durchgeführt werden.
Im unten beschriebenen Vorgehen wurde eine hybride Strategie verfolgt: Sämtliche JLAG-Attribute, die sich in der Datenbank auf mehrere Tupel verteilen,
das heißt, die mengenwertig sind, werden über separate Abfragen ermittelt. Betroffen sind also zum Beispiel für Proplets aller Typen trc, sem und cat. Diese
Abfragen müssen dann natürlich Selektionen beinhalten, die als Bedingungen
die der Joins besitzen, die sie ersetzen. Dagegen werden die Werte aller einfachen Attribute über echte“ Join-Anwendungen berechnet.
”
Der Vorteil dieser Lösung besteht vor allem in einer besseren Übersichtlichkeit
hinsichtlich der resultierenden Relationen; außerdem ergibt sich auch, wenn
spä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 verstä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)
Fü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 Traversionszähler eines Proplets wiederherzustellen, müssen sämtliche
einzelnen Zeitstempelwerte aus der Relation trc passend zu einem bestimmten (prn,wdn)- Schlü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 für die Ausgabe an JLAG benötigen. Dies
betrifft die Attribute ctn, ctp, mdr, sem und cat.
ctn: Für die Rekonstruktion des JLAG-Attributs ctn fehlt in der Relation
verbproplet nur das Konzept des Verbs der nächsten Proposition. Um dieses zu
berechnen, genügt ein Join mit den Basisrelationen verbproplet und proplet; da
jedoch nicht jede Proposition einen Nachfolger haben muss, ist ein Outer-Join
nötig. Zuerst kö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 können, müssen einerseits die Propositionsnummer
und das Konzept ermittelt werden, das das Verbproplet der vorigen Proposition besitzt, andererseits die mögliche Konjunktion bestimmt werden. Als Basis
dafür lässt sich folgende Zwischenrelation einführen, die natü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 bezüglich eines bestimmten Wertes für prn beinhalten. Für die Ausgabe
wird jedoch nur das Konzept des Adverbs benötigt, so dass anschließend eine
Projektion durchgeführt wird.
verbmdr = P ROJ[concept](SEL[prn = x]adverbialproplet)
arg: Für die Rekonstruktion von arg genügt analog zu mdr ein Teil der entsprechenden Relation nounproplet, der sich wie folgt spezifizieren lässt:
verbarg = P ROJ[concept, argn](SEL[prn = x]nounproplet)
Das Attribut argn wird in der Projektionsliste benö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 für ein proplet zu erhalten. In
einer höheren Schicht, das heißt, auf Programmiersprachenebene, mü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 müssen. Dies geschieht
wie folgt:
fnc: Dies ist das einzige der fehlenden Attribute, das nicht mengenwertig ist.
Somit wird für die Ermittlung der korrekten Werte ein Join durchgeführt. Dieser basiert einerseits natürlich auf nounproplet, andererseits auf einer Relation,
die sich wie folgt festlegen lässt:
f ncpartner = REN [prn, f nc](P ROJ[prn, concept]verbproplet)
concept stellt den eigentlichen Wert von fnc dar, wohingegen prn für den anschließenden Join benö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 für die eindeutige Identifikation eines Nounproplets die Werte für prn und wdn benö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
Gegenü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 über die Durchführung eines Join der Relation adverbialproplet
hinzugefü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 Ausdrücke der Form
advsemvalues = SEL[prn = x, prn = y]advsem
advcatvalues = SEL[prn = x, prn = y]advcat
Adnomina
Auch für Adnomina muss noch die Oberfläche des Modifikanden ermittelt werden. Diese ist in der Relation nounproplet enthalten; natürlich könnte hier
auch, genau wie schon in einigen der anderen Fälle, proplet verwendet werden.
Der nötige Join zielt auf die Fremdschlüsselbeziehung (prn,mddnoun) ab, so
dass folgender Term das gewü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
Fü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 Ausdrücke lassen sich die vollständigen Mengen
der Verben, Nomina, Adverbien und Adnominale durch Benutzung der entsprechenden Terme ermitteln; für die Darstellung der in 3.3 aufgeführten Zugriffe
auf die Datenbank mü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 eingeführten Relationen:
SEL[prn = 3, concept = katze]nounproplet′
Auf diese Weise kö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 für Schritt
entwickelt worden, um einen verständlichen Überblick über die Methodik der
Anfragestellung zu geben; in der tatsächlichen Implementierung werden sich
diese jedoch nicht unbedingt 1:1 wiederfinden lassen, da man viele Ausdrü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 erwähnt bedarf die Umsetzung des konzeptionellen Schemas im relationalen Kontext nicht viel Arbeit: Die schon definierten
Relationen müssen einfach mit Hilfe einer Definitionssprache ins System eingebracht werden; zusätzlich müssen nur anwendungsorientierte Optimierungen
und systemspezifische Erfordernisse berücksichtigt werden.
6.1 MySQL
MySQL ist das am weitesten verbreitete Open-Source-Datenbanksystem im relationalen Sektor. Sie ist für eine Vielzahl von Plattformen vefügbar und bietet
eine weitgehende Unterstützung der Standard-Anfragesprache SQL.
Die Hauptkomponente stellt ein Datenbankserver dar. Dieser lä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
können.
Lange Zeit fehlten MySQL viele Merkmale, die vom SQL92-Standard definiert
sind und kommerzielle Datenbanksysteme schon lä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 wären, und auch Unteranfragen sind in den derzeit finalen
Versionen nicht mö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 gefü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 für diese Arbeit
keine Rolle spielen, da die Implementierung in einem rein relationalen System
geschehen soll. Die Referenz fü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 fü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, Einfügen, Modifizieren und Löschen. Dieser Teil von SQL implementiert also unter anderem
grundsä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 weiterfü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 nötigen Kommandos dieses SQL-Teiles; die DCL soll später
erklä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 übernommen. Folgende
”
EBNF-Beschreibung definiert einen Teil seiner Syntax, der für diese Arbeit
genü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 Primärschlüssel definiert, mit FOREIGN KEY“
”
”
Fremdschlüssel. Für letztere lässt sich festlegen, was geschehen soll, wenn ein referenziertes Tupel gelöscht wird ( ON DELETE“) oder sich sein Schlüsselwert
”
ändert ( ON UPDATE“): Im Falle der Option CASCADE“ wird die Löschung
”
”
beziehungsweise Änderung auch auf das referenzierende Tupel angewendet, mit
SET NULL“ wird in beiden Fällen der Wert der Fremdschlüsselattribute auf
”
null gesetzt. Als dritte Möglichkeit existiert RESTRICT“, mit dem die ge”
samte Modifikation zurückgewiesen wird. Welche Alternative bevorzugt wird,
hängt von der Anwendungswelt ab.
Über INDEX“ lassen sich Indexe erstellen, durch die Anfragen, die die auf”
geführten Attibute betreffen, beschleunigt werden kö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
unausgefüllt, also null sein darf.
Der SQL-Standard spezifiziet auch Datentypen. Die für diese Anwendung wichtigsten sind fü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 führt); für Zeichenketten wird VARCHAR mit der Zahl der möglichen Zeichen als Parameter
benutzt.
Beispielsweise fügt folgendes Statement der Datenbank eine Relation namens
KFZ hinzu, deren Primärschlüsel fahrgestellnummer“ ist und über ein Fremd”
schlü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
Fremdschlüsselattributs, das ihn referenziert, auf null gesetzt werden; dies wird
durch ON DELETE SET NULL“ festgelegt. Wenn sich der Primärschlüssel”
wert eines referenzierten Tupels in person ändert, soll der Wert von besitzer“ in
”
kfz angepasst werden. Diese beiden Regeln begründen sich in der Anwendungswelt. Auch über die UNIQUE-Zeile wird eine Regel aus der nachzubildenden
Miniwelt eingebracht, die besagt, dass Kennzeichen eindeutig sein müssen.4
Ebenso existieren CREATE-Kommandos für Sichten (Views). Views sind im
Prinzip nichts anderes als in der Datenbank gespeicherte DML-Anfragen. Sie
können in Statements wie Tables verwendet werden; erst bei ihrer Benutzung,
also nicht bei ihrer Definition, wird das Statement ausgeführt. Somit ergibt sich
stets ein aktuelles Bild der Relationen, die von der Anfrage betroffen sind, ohne
dass der Update-Aufwand bei Erstellung einer zusätzlichen Relation anfallen
würde. Hierin besteht neben der kompakteren Anfrageformulierung für den
End-Benutzer auch der Hauptvorteil von Sichten. Zusätzlich schaffen Sichten
auch eine zusätzliche Abstraktionsebene, die es erlaubt, individuell angepasste
Schemata fü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. Natürlich ist seine
”
wichtigste Erscheinungsform die in einem ALTER TABLE“-Statement. Da”
mit lassen sich Relationenschemata nachträglich modifizieren, das heißt, zum
Beispiel Attribute hinzufügen, Indexe erstellen, Schlüssel definieren oder Constraints ä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-Identitätsnummer dargestellt.
Somit hat auch dieses Attribut die Schlüsseleigenschaft und könnte als Primärschlüssel
dienen. Jedoch sind Zeichenkettenattribute aus Performanzgründen wenn mö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“ hinzugefügt:
”
ALTER TABLE kfz
ADD farbe VARCHAR(20);
Eine ausführliche Dokumentation hierfür genau wie für die anderen Operatoren
liefert die angegebene Literatur.
6.2.2 Implementierung der WURM-Relationen
Hauptsächlich besteht die Implementierung der fü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 Portabilität und
Verständlichkeit beeinträchtigt.
Spalten, die in jedem Tupel einen Wert aufweisen müssen, sollten unbedingt
mit der NOT NULL“-Einschränkung versehen werden, um die logischen Inte”
grität der Daten zu gewä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 müssen daher nullwertig sein dürfen.
• ctncnj und ctn in verb sind optional, da Propositionen nicht immer Nachfolger besitzen und mit diesen nicht immer über Konjunktionen verknüpft
sein müssen.
• Primärschlüssel-Attribute dürfen von Natur aus nicht null sein. Somit
entfällt auch für sie die zusätzliche Spezifikation.
Somit lassen sich durch folgende Standard-konforme Kommandos die gewü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 Gründen der Übersichtlichkeit nicht mit aufgeführt; für den
Fremdschlüssel ctn“ gilt SET NULL“ bei Löschungen, ansonsten stets ON
”
”
”
DELETE CASCADE ON UPDATE CASCADE“.5
Nun empfiehlt es sich, Indexe anzulegen, um die anwendungsspezifischen Anfragen schneller ausführen zu können. Dies geschieht fü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 fü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 müssen bei der Verwendung von MySQL einige Besonderheiten beachtet
werden:
• Da die Benutzung der transaktionalen Fähigkeiten von MySQL 4.0 gerade im Hinblick auf die folgenden, komplexen Einfügevorgänge wünschenswert ist, sollte auf die sogenannten InnoDB-Tables zurückgegriffen werden. Diese bieten eine ACID-konforme6 Anfrageverarbeitung. InnoDB
bietet als erster Speicherungsmanager in MySQL auch die Gewä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 über Attributen, deren Werte mit FOREIGN KEY“-Attributen in
”
anderen Relationen referenziert werden. Auch die Fremdschlüsselattribute selbst müssen indexiert werden. Da durch Primärschlüssel-Definitionen
automatisch Indexe angelegt werden, betrifft dies jedoch nur wenige Stellen der CREATE-Statements; und auch wenn die Fremdschlüsselattribute
einen Teil eines vorhandenen Indexes darstellen, muss keine zusätzliche
Definition vorgenommen werden. Somit sind die folgenden Ergänzungen
nötig:
CREATE INDEX prnwdnVerbIndex ON verb (prn, wdn);
CREATE INDEX ctnVerbIndex ON verb (ctn);
CREATE INDEX prnmddNounIndex ON noun (prn, mddnoun);
All diese zusätzlichen Festlegungen kö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 Anhängen von TYPE = InnoDB“ hinter der
”
letzten schließenden Klammer.
Bevor die Relationen mit den gerade gezeigten Statements erstellt werden
können, muss jedoch noch eine Datenbank definiert werden, der die Tables
angehören sollen. Dies geschieht ebenfalls durch ein CREATE-Kommando, das
jedoch deutlich kürzer ausfällt. Im folgenden wird davon ausgegangen, dass mit
CREATE WURM;
5
Diese Festlegungen sind aber eher zweitrangig, da Änderungen der Primärschlüssel praktisch nicht vorkommen und Lö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 können mit Hilfe von Kommandos der DCL neue Nutzer
erstellt werden; standardmäß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 natürlich wü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 kö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 hinzufügen, denen dann
über die IDENTIFIED BY“-Klausel ein Passwort zugewiesen wird, mit dem
”
sie sich anmelden müssen. Mögliche Privilegien sind z.B. bestimmte DMLOperatoren ausführen zu können, aber auch administrative Rechte zum Löschen
oder Erstellen von ganzen Tables. Folgendes Statement erstellt einen neuen Benutzer namens moritz, der sich mit dem Passwort katze“ anmelden muss. Er
”
soll sämtliche Rechten auf allen Tables aller Datenbanken besitzen und selbst
GRANT-Kommandos benutzen dürfen:
GRANT ALL PRIVILEGES
ON *.*
TO moritz@localhost
IDENTIFIED BY ’katze’
WITH GRANT OPTION;
REVOKE“-Statements sind ähnlich aufgebaut:
”
REVOKE privilegien [(spalten)] [, privilegien [(spalten)] ...]
ON {table | * }
FROM benutzerername;
Auf eine weitergehende Erläuterung soll an dieser Stelle verzichtet werden, da
die DCL fü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 höheren Grad an Abstraktion
erleichtert sich die Benutzung für den Nutzer erheblich. In diese Kerbe schlägt
auch der Ansatz der Entwickler von SQL, die Sprache durch Verwendung von
möglichst natürlichsprachlichen Kommandos verständlich zu gestalten. Ob diese Absicht erfolgreich umgesetzt wurde, sei dahingestellt.
In SQL stellt die Data Manipulation Language“ (DML) die Kommandos zur
”
Anfrageformulierung zur Verfügung. Die folgende Beschreibung der einzelnen
Operatoren soll Aufschluss über ihre Funktionalität und Verwendung geben.
7.1 Operatoren der DML
Die DML umfasst Kommandos zum Abfragen, Modifzieren, Löschen und natürlich
notwendigerweise auch Einfügen von Daten. Die folgenden Unterkapitel erlä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 möglich. Um dann unter Umständen gleichnamige Attribut un1
2
Bis auf die Einfügeoperation INSERT, welche Tupel-orientiert funktioniert
Darin zeigt sich die Verbindung zur relationalen Algebra.
51
terscheiden zu können, wird eine Punktnotation benutzt, wie sie in ähnlicher
Weise auch in Sprachen wie C verwendet wird.
SELECT
FROM
relation1.attribut1, relation2.attribut2
relation1, relation2;
Es besteht die Möglichkeit, Tables in der FROM-Klausel Aliasnamen zu erteilen, da unter Umständen eine Relation mehrmals vorkommt. Diese zusätzlichen
Bezeichnungen werden direkt hinter dem Relationennamen aufgeführt. Ebenso
lassen sich Attribut fü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 lässt. Die Selektion geschieht
über den sogenannten WHERE-Operator.
Selektion
WHERE“ dient dazu, Restriktion auf Relationen durchzufü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 durchgeführt,
”
da alle Attribute (durch ’*’) in der Ergebnisrelation vorkommen. Doch natü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 verknüpfte, komplexe Selektionsbedingun”
gen. Selbstverständlich sind nicht nur Attribut-Wert-, sondern auch AttributAttribut-Vergleiche zulässig.
Joins
In SQL gibt es für den entsprechenden relationalen Operator das Kommando
JOIN“. Es lä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 eingeführten Table kfz und einer zusätzlichen namens
Person mit der Definition
CREATE TABLE person
( personID INTEGER,
vorname VARCHAR(16),
nachname VARCHAR(20),
PRIMARY KEY(personID) );
lä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 gemäß seiner Definition in der relationalen Algebra der Join zweier Relationen auf das kartesische Produkt dieser mit anschließender Selektion
zurückführen lä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 nämlich die Durchführung des kartesischen Produkts der beiden Tables.
Die Durchführung eines Join hat ihre größte Bedeutung in der Kombination
von Tupeln, die über eine Fremdschlüsselbeziehung verknüpft sind; somit hat
dieser Operator für diese Arbeit eine enorme Bedeutung.
Division
In SQL gibt es für die Division kein eigener Operator; vielmehr muss dessen
Funktionalität über ein sehr komplexes Statement basierend auf anderen Kommandos nachgebildet werden. Da die Division verhältnismäßig selten benötigt
wird und vor allem auch in der zu entwickelnden Datenbank keine Rolle spielen
wird, soll auf dessen Erläuterung verzichtet werden.
Zusammenfassung DML-SELECT
Über diese vier relationalen Operatoren hinaus gibt es noch eine Menge weiterer
Kommandos, die in Anfragen verwendet werden kö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 berücksichtigen kann: Hierfür gibt es die sogenannten Aggregatsfunktionen wie
53
• max(): Maximumsberechnung bestimmter Attribute bezüglich Gruppen
• min(): Minimumsberechnung - “ • avg(): Durchschnittsberechnung - “ • count(): Zählen von Tupeln in Gruppen
• ...
Diese Funktionen kö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 aufgefü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, müsste die Projektionszeile in SELECT besitzer, count(*)“
”
geändert werden.
Durch ORDER BY“ lassen sich Tupel für die Ausgabe auf-(ASC) oder ab”
steigend (DESC) sortieren. Dies geschieht nach der mö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 gehö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 Ä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
lässt sich festlegen, welchen Bedingungen Tupel unterliegen müssen, damit sie
modifiziert werden. Eine Anwendung eines UPDATE-Statement im Rahmen
der eingeführten Relationen wird zum Beispiel im Falle einer Ummeldung eines Autos nötig:
UPDATE
SET
WHERE
54
kfz
kennzeichen = ’S-QL 92’, besitzer = 23
fahrgestellnummer = 12345678;
7.1.3 Löschungen
Das Löschen von Tupeln geschieht mit dem DELETE-Kommando, das folgendermaßen aufgebaut ist:
DELETE FROM tablename
[WHERE selektionsbedingung];
Beispielsweise lässt sich mit
DELETE FROM kfz
WHERE fahrgestellnummer = 12345678;
ein Automobil aus der Relation kfz entfernen.
7.1.4 Einfügungen
Das INSERT-Statement ermöglicht das Einfü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 übereinstimmen. Folgende Anweisung erweitert die Relation Person um
eine Zeile mit den Attributwerten 22 für personID, ’Tim’ für Vorname und
’Berners-Lee’ für Nachname.
INSERT INTO person (nachname, vorname, personID)
VALUES (’Berners-Lee’, ’Tim’, 22);
Natürlich müssen die einzufü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 erwähnt, werden diese Anfragen jedoch nicht 1:1 umgesetzt, da sich
bestimmte Teilausdrücke zusammenfassen und sich so übersichtlichere DMLStatements erstellen lassen.
Im Folgenden sollen zuerst die SQL-Kommandos beschrieben werden, die nötig
sind, um Proplets aus den einzelnen Tables zu rekonstruieren. Anschließend
wird dargestellt, wie Proplets aus dem JLAG-System in die Datenbank eingefügt werden können.
7.2.1 Suchanfragen
Verbproplets
Das Kernstück fü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 zugehörigen Projektionen und Umbenennungen sind mit in die
übergreifende SELECT-Klausel aufgenommen.
Für jedes Verbproplet müssen jedoch zusätzlich noch die Werte für trc, arg,
mdr, sem und cat ermittelt werden. Da dies jedoch nicht per Join geschieht,
müssen für jedes aufzubauende Proplet einzelne Anfragen gestellt werden; diese
beinhalten entsprechend der Ausdrücke in 5.3 WHERE-Klauseln, die die Tupel
auf die zum aktuellen Proplet passenden restringieren.
Das relevanten Traversionszä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 können die Resultatstupel di”
rekt in die trc-Liste des Proplets aufgenommen werden.
Der Ausdruck fü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 für
mdr analog:
56
SELECT
FROM
WHERE
AND
AND
concept
proplet, adverbial
adverbial.prn = ?
adverbial.prn = proplet.prn
adverbial.wdn = proplet.wdn
In beiden Fällen muss auch hier für das Fragezeichen der Wert von prn des
jeweiligen Proplets eingesetzt werden.
Um sem und cat wiederherstellen zu können, bedarf es der folgenden zwei,
ä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 für sem und cat werden
erst auf der höheren Ebene der programmiersprachlichen Einbettung in JLAG
zusammengebaut. Diese werden dann anhand des Wertes von semcatn zusammengefasst.
Nominalproplets
Die Repräsentation der Relation nounproplet’ übernimmt folgendes SQL-Konstrukt,
das als Basis fü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 enthält also die Attribute prn, wdn, concept, idy
und fnc. Es fehlen also wiederum trc, sem, cat und mdr. Der Traversionzähler
wird ebenso wie bei Verbproplets rekonstruiert. Nur leichte Unterschiede ergeben sich bezüglich der Anfragen für die anderen drei Attribute: Es muss jeweils
ein zusätzliches Attribut mit in der Selektion verarbeitet werden, da Nounproplets erst durch die Hinzunahme von wdn eindeutig identifiziert werden
können. Außerdem unterscheiden sich natü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 fü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 fü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 können alle Attribute für die korrekte Präsentation
in JLAG ausgegeben werden. Um spezielle Proplets gemäß der funktionalen Anforderungen zu erhalten, müssen die Statements für die Basisrelationen nounproplet’, verbproplet”, adnominalproplet und adverbialproplet um WHEREKlauseln erweitert werden.3 Darauf wird im nächsten Kapitel eingegangen.
3
Genau genommen werden natürlich AND-Klauseln hinzugefügt.
59
60
8
Benutzung der Datenbank
in JLAG
Um die Datenbank für JLAG nutzbar zu machen, bedarf es nun einer Integration in den Java-Code. Wie schon erwähnt geschieht dies über die Implementierung des Interfaces DBIF1 . Die einzelnen darin enthaltenen Methoden müssen
ihrer Funktionalität entsprechend SQL-Kommandos an den Datenbank-Server
absetzen und deren Ergebnisse fü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 nötige Paket
sql“ enthalten. Es stellt eine API4 zur Verfügung, mit der sich vollkommen
”
Datenbanksystem-unabhängiger Code erzeugen lässt. Darüberhinaus ist allein
ein passender JDBC-Treiber nötig, der die Java-Aufrufe für das spezielle System ü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 natü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 nötigen Algorithmen vorgestellt.
8.2.1 Einfügungen
Wenn der Datenbank ein Proplet hinzugefügt werden soll, ist stets die Relation proplet“ betroffen; die nötigen Attributwerte für prn, wdn und con”
cept können ohne weiteres der JLAG-Struktur entnommen werden. Genauso
würden nun auch trc-Werte eingetragen, indem die Liste aus der Merkmalstruktur extrahiert und in einzelne Zeitmarkenwerte aufgeteilt würde. Jedoch
ist dies momentan für das Einfügen irrelevant, da der Datenbank nur untraver1
siehe Kycia 2004
Das Akronym JDBC erinnert an Microsofts ODBC, was für Open DataBase Connectivity“
”
steht. Jedoch bestreiten die Entwickler, dass JDBC Java DataBase Connectivity“ bedeuten
”
soll. Dennoch ähneln sich die beiden Produkte in ihrem Funktionalität.
3 Java development kit
4 application programming interface
2
61
sierte Proplets hinzugefügt werden.
Die weiteren Schritte sind abhängig davon, welchem Typ ein Proplet angehört.
• Bei Verben muss aus dem Wert von ctn die Nummer der nächsten Proposition und die möglicherweise vorhandene Konjunktion extrahiert werden.
• Direkt im einzufügenden Nounproplet ist idy enthalten. Dagegen muss
der Wert für argn mit Hilfe der Liste arg im zugehörigen Verbproplet
berechnet werden.
• Bei Adnominalen muss die Wortnummer des modifizierten Nounproplets
ermittelt werden, um das Attribut mddnoun aufzufüllen.
• Adverbiale erfordern keine speziellen Operationen.
Darüberhinaus müssen die sem- und cat-Werte der JLAG-Proplets verarbeitet
werden. Hier sind nur die betroffenen Relationen vom Typ abhängig, die einzufügenden Tupel besitzen einen identischen Aufbau.
Zusammenfassend lässt sich der Einfü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. Hierfür sind Standardanfragen definiert, die durch
zusätzliche Selektionen erweitert werden können. Diese entsprechen denen aus
Kapitel 7.2.
Zu Beginn eines jeden Denkprozesses wird stets eine Methode aufgerufen, die
sä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 für Verben eine weitere ANDKlausel angehängt wird.
Aus der resultierenden Liste wird von JLAG ein bestimmtes Proplet ausgewählt. Diese Entscheidung kann zufällig erfolgen oder auch anhand der Zahl
der bisherigen Traversionen.
Anfragen bei intrapropositionaler Navigation
Soll nun die komplette Proposition rekonstruiert werden, müssen die restlichen
Proplets ermittelt werden. Dazu dient im vorhandenen Java-Interface eine zweite Methode, die als Parameter ein Muster-Proplet erhält und folgendes Schema
besitzt:
HOLE PROPLET (Proplet muster)
anfrage := standardanfrage + zusaetzliche restriktion;
STELLE ANFRAGE (anfrage);
Fü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 möglich ist, ist
das Attribut fnc für diese Anfrage natü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 für das gefundene Nounproplet gesucht werden,
sieht das Suchmuster ä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 gehörige Adverbiale können über folgende Anfrage ermittelt
werden:
anfrage := standardadverbialanfrage +
SELEKTIONSBEDINGUNG (prn = muster.prn UND
concept = muster.adj);
63
Anfragen bei extrapropositionaler Navigation
Die extrapropositionalen Beziehungen können ebenfalls leicht über zusä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. Für eine Anfrage genügt der Methode also ein Muster, das
[prn: <aktueller ctn-wert> ]
enthält. Damit wird die Anfrage also um nur eine zusätzliche Restriktionsklausesl erweitert.
anfrage := standardverbanfrage +
SELEKTIONSBEDINGUNG (prn = muster.prn);
Rückwärtsnavigation lässt sich ä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 Identität besitzen, genügt
folgende Anfrage:
anfrage := standardnounanfrage +
SELEKTIONSBEDINGUNG (idy = muster.idy);
8.2.3 Löschungen
Im zu implementierenden Interface gibt es eine einzige Methode, die Löschungen auf den Relationen vornimmt; diese setzt die gesamte Datenbank zurück,
so dass für jede Table nur ein DELETE FROM“-Statement ohne weitere Re”
striktionen ausgeführt werden muss.
8.2.4 Modifikationen
Wenn Proplets bei der Navigation durch LA-Think verarbeitet werden, muss ihr
Traversionszählerwert modifiziert werden. Vor allem hierfür existiert in der Datenbankenschnittstelle eine Methode, die die Werte der Attribute eines Proplets
ändern kann. Als Ü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 würden nun alle Relationen, die Tupel des entsprechenden
Typs aufnehmen, mit den neuen Werten über UPDATE-Statements aktualisiert. Tatsä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 Hinzufügen jeweils eines neuen Tupels in die Relation trc.
64
9
Zusammenfassung und
Ausblick
Das entwickelte Schema und die entsprechende Implementierung sollten allen
Anforderungen genügen, die an eine Wortbank seitens des JLAG-Systems gestellt werden.
Die zur Rekonstruktion der einzelnen Proplets nö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 für den Im- und Export der Proplets nötigen Konvertierungen auf Java-Ebene; hierin zeigt sich, dass die JLAG-Strukturen von Natur aus nicht gerade perfekt mit relationalen Datenbanken harmonieren. Aber
selbstverständlich können alle Informationen von der Datenbank aufgenommen
und wiedergegeben werden. Die beschriebenen Konzepte sollten jederzeit auf
andere relationale Datenbanksysteme anwendbar sein, auch weil auf möglichst
SQL-konforme Implementierung geachtet wurde.
Durch die vorhandenen Redundanzen in manchen Attributen der Proplets entstehen vor allem für Suchanfragen auf den Datenbestand zusä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
zukünftige Anforderungen vorbereitet ist. Teilweise sind in den Relationen
schon Attribute enthalten, aber auch Erweiterungen sollten ohne weiteres möglich
sein. Ein verhältnismäßig großer Schritt wäre dabei die Einführung von Propositionen mit mehreren Verben. Doch auch dies würde hauptsächlich nur zur
Hinzunahme des Attributes wdn“ zum Primärschlüssel der Relation verb“
”
”
und zum Anpassen der entsprechenden Fremdschlüssel führen. Auch die Anfragen würden modifiziert werden müssen, doch auch dies könnte nach Schema
”
F“ abgewickelt werden.
Unter Berücksichtigung der Möglichkeiten, die ein Datenbanksystem bietet,
wäre dagegen eine Modifikation des Java-Interfaces denkbar. Zum Beispiel sollte die Funktionalität der Methode traverse“, die darin besteht, auf Basis einer
”
Menge von aus der Datenbank extrahierten Proplets bestimmte herauszufiltern, idealerweise komplett vom Datenbanksystem übernommen werden: Über
passenden Suchanfragen auf dem Datenbestand ist diese Aufgabe ohne weiteres
zu lösen.
Zur Zeit wird am Lehrstuhl für Computerlinguistik an der Universität ErlangenNürnberg von Martin Hampl eine Korpusdatenbank samt zugehöriger Anfragesprache entwickelt. Dabei stellt sich die Frage, inwiefern Zusammenhänge
zwischen dieser und der im Rahmen dieser Arbeit erstellten Datenbank ergeben und wie diese eventuell zu einer Integration führen könnten.
65
Ein Korpus ist eine Sammlung von Texten in einer bestimmten Sprache, die
als Grundlage für statistische Untersuchungen dienen soll. Somit stellt die
Korpuslinguistik eine Art Grunddisziplin für andere Teilbereiche der Sprachwissenschaften dar. Abhängig vom Verwendungszweck des Korpus geschieht
die Auswahl der Texte; um den Umfang einer Sprache umfassend zu erfassen, empfiehlt es sich, mö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, sämtliche in den Texten
enthaltenen Wörter zu speichern. Dabei ist nur die tatsächlich vorkommende
Wortform, das Token, von Bedeutung, das heißt genau das, was im Kontext
dieser Arbeit als Oberflä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
erklärt sich auch ein zweites abweichendes Merkmal, nämlich, dass in Korpusdatenbanken für jede vorkommende Wortform der Eingabetexte Einträge
vorgenommen werden. In einer Wortbank sind direkt nur Verben, Nomina und
Adjektive enthalten; alle anderen Wörter wie zum Beispiel Artikel oder Hilfsverben sind in die entsprechenden Proplets mit hineincodiert.
Interessant fü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 durchführen zu
können. Daher könnte die Relation, die durch folgendes SQL-Statement beschrieben wird, das Kernstü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
hört“, der der Korpusdatenbank zugrunde liegt, und in seiner Wortbank spei”
chert, lässt sich jedem generierten Proplet ein Token der Korpusdatenbank
zuordnen.2 Dies liese sich auf Fremdschlüsselbeziehungen zwischen Tupeln der
Relationen proplet und token abbilden. Somit könnte dem Agenten auf einfache
Art und Weise das Wissen darum vermittelt werden, in welchem Zusammenhang ein Wort, das durch ein bestimmtes Proplet repräsentiert wird, benutzt
wurde: Das Wort Birne“ hat zum Beispiel in einem Artikel einer Zeitschrift
”
fü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 wä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 Gedächtnis dar.
1
Für amerikanisches Englisch 1967 von Kučera und Francis erstellt
Theoretisch ließen sich mehrere zuordnen, nämlich nicht nur die Tokens, die Inhaltswörter
reprä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 nü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. Mü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 für Computerlinguistik, FriedrichAlexander-Universität Erlangen-Nürnberg
[Hausser TT 2003] Hausser, R. (2003): Turn Taking in Database Semantics. Abteilung für Computerlinguistik, Friedrich-Alexander-Universität
Erlangen-Nürnberg
[Künneth 2001] Künneth, Th. (2001): Datenbankgestützte Speicherung von
Korpora. Magisterarbeit, CLUE-Arbeitsberichte Nummer 4, Abteilung für
Computerlinguistik, Friedrich-Alexander-Universität Erlangen-Nürnberg
[Kycia 2004] Kycia, A. (2004) Implementierung der Datenbanksemantik in
Java. Magisterarbeit in Bearbeitung, Abteilung für Computerlinguistik,
Friedrich-Alexander-Universität Erlangen-Nürnberg
[MySQL] MySQL Reference Manual. Dokumentation
Datenbanksystems, erhältlich unter www.mysql.com
des
MySQL-
67