04-MKD-2003-R.SE01 Seminar „Terminographie“ 2. Semester, Donnerstag um 11:15, H001

↗ 04-005-1012-R.SE01 Seminar „Terminographie“ 6. Semester, Donnerstag um 13:15, H001
↗ 04-MKD-2003-R.SE01 Seminar „Terminographie“ 2. Semester, Donnerstag um 11:15, H001

Design einer Termbank

Begründung des Vorhabens

Die nachstehende Folie führt an einen nichtlinguistischen Aspekt der Organisation von Daten heran: die Normalisierung. Solche rein technologischen Wissensbausteine können aus verschiedenen Gründen auch für Dolmetscher und Übersetzer nützlich werden. Auf der Hand liegt zunächst, dass Power-User von Termbank-Systemen, wie Translatoren sie sind, auch informiert sein dürfen über das, was diese Systeme leisten und wie sie funktionieren, wenn sie funktionieren. Ganz beiläufig hilft ein Nachdenken über Datenbanken den Blick auf Fragen der Terminographie und Lexikographie weiten. Und schließlich ist es das Schicksal aller Interdisziplinen, dass sich für sie niemand so recht zuständig fühlen möchte. Auch Datenbankentwickler wissen nämlich nicht, wie Termbanken modelliert werden müssen und sind ihrerseits auf Terminographen angewiesen, die sich sachgerecht ausdrücken können und den Entwickler verstehen. Allein aus Gründen der Berufsfindung (und damit Beschäftigungsfähigkeit) wäre es wichtig, am Wissen hinter dem ganzen Gemacht-Bekommen zu partizipieren.

Aufgabe

Herstellung einer begriffsorientierten Datenbank, in der die folgenden Dinge eingetragen und ausgelesen werden können:

  • Terminus Russisch
  • Terminus Deutsch
  • Wortart
  • Aspekt

Vorab: Glossar aus der Datenbanktheorie

Relation: Tabelle einer Datenbank

Tupel: Zeile einer Datenbank. Synonym: Datensatz.

Attribut: Spalte einer Datenbank. Synonym: Feld.

Primärschlüssel: Für die eindeutige Identifikation eines Tupel verwendetes Attribut einer Relation. Oft ein numerischer Wert  Kundennummer in der Relation „Kunden“.

Fremdschlüssel: Nichtschlüsselattribut einer Relation, das auf einen gleichlautenden Primärschlüssel in einer übergeordneten Relation zeigt  Kundennummer in der Relation „Rechnungen“ (zeigt auf Kundennummer in der Relation „Kunden“).

Normalisierung: Herstellung von Redundanzfreiheit einer Datenbank durch deren Zerschlagung in Relationen. Aus einer komplexen Tabelle werden also mehrere einfache (nicht mehr teilbare). Ziele der Normalisierung sind u. a. Konsistenz (Datenintegrität) sichern, Voraussetzung für Filter- und Sortierfunktionen schaffen, Performanz der Datenbankanwendung verbessern, Personal- und Hardwareaufwand senken, Strom sparen. Speziell in der Terminographie ist Normalisierung etwa für die Bidirektionalität der Termabfrage nötig.

Abhängigkeit, funktionale: Attribut A ist von Attribut B funktional abhängig, wenn zu jedem Wert von A genau ein Wert von B existiert. Hiervon können wir ausgehen, wenn wir eindeutig von A auf B schließen können, und zwar (im Gegensatz zur transitiven Abhängigkeit) direkt  Wir können vom Attribut „Abteilung“ auf das Attribut „Abteilungsnummer“ schließen. Also ist das Attribut „Abteilungsnummer“ vom Attribut „Abteilung“ funktional abhängig.

Abhängigkeit, voll funktionale: Man kann auch einen zusammengesetzten Primärschlüssel definieren = eine Kombination aus mehreren Attributen zum Primärschlüssel erklären  Nehmen wir an, wir möchten die für eine Kassenbuchung verantwortliche Mitarbeiterin ermitteln. Wenn wir nur den Wochentag kennen (Attribut „Wochentag“, etwa „2“ für Dienstag), bekommen wir den Namen nicht heraus, weil am Dienstag mehrere Kassiererinnen da waren. Wenn wir nur die Kasse wissen (Attribut „Kasse“, z. B. „9“ für die Kasse ganz rechts), bekommen wir den Namen auch nicht heraus, weil an dieser Kasse über die Woche unterschiedliche Kassiererinnen gesessen haben. Wohl aber lässt sich die Kassiererin aus der Kombination der beiden Attribute ermitteln. (Wir unterstellen, dass eine Kassiererin am Tag nicht die Kasse wechselt.) Der zusammengesetzte Schlüssel hieße hier „2‑9“. Voll funktional abhängig ist ein Attribut (in unserem Beispiel „Kassiererin“), das vom gesamten Schlüssel (hier „2‑9“) abhängt und nicht nur von einem Glied des Schlüssels (von „2“ oder von „9“). Existiert kein zusammengesetzter Schlüsselkandidat, so sind voll funktional und funktional dasselbe.

Abhängigkeit, transitive: Attribut C ist von Attribut A transitiv abhängig, wenn B von A funktional abhängig ist und C von B. Der Verdacht einer transitiven Abhängigkeit drängt sich auf, wenn ein Nichtschlüsselattribut „starr“ an ein anderes Nichtschlüsselattribut gekoppelt ist  Wenn die Attribute „Abteilung“ und „Abteilungsnummer“ Nichtschlüsselattribute in ein und derselben Relation sind, so besteht zwischen ihnen eine transitive Abhängigkeit. Solche transitiven Abhängigkeiten werden in der dritten Normalstufe in voll funktionale umgewandelt, indem die betroffenen Attribute in eine separate Relation ausgesiedelt werden. Das determinierende Nichtschlüsselattribut wird in der neuen Relation dann Primärschlüssel.

Kardinalität: Beziehungstyp, der besagt, wie viele Datensätze (Entitäten) einer Relation (eines Entitätstyps) mit genau einem Datensatz einer anderen Relation in Beziehung stehen. Es existieren drei Kardinalitäten:

  • 1:1 (Ein Student hat genau eine Matrikelnummer und eine Matrikelnummer ist genau einem Studenten zugewiesen.)
  • 1:n (Ein Student ist an genau einem Tag immatrikuliert worden; an einem Tag sind aber mehrere Studenten immatrikuliert worden.)
  • n:m (Ein Student besucht mehrere Seminare, und in einem Seminar sitzen mehrere Studenten.)

Die Ermittlung der Kardinalitäten hilft uns bzw. der Datenbankanwendung verstehen, wie die Relationen selbst gestaltet werden müssen. Bei einer 1:n-Beziehung etwa genügt ein Fremdschlüssel in der untergeordneten Relation; bei einer n:m-Beziehung muss zwischen den Relationen eine so genannte Auflösungstabelle vermitteln, also eine Tabelle mit zwei Fremdschlüsseln.

Auflösungstabelle: Tabelle, die zwischen zwei Relationen vermittelt. Eine Auflösungstabelle hat nur Fremdschlüssel (keine Primärschlüssel), kann also nur „zeigen“.

Gegeben sei eine vereinfachte zweisprachige Termbank mit vier Spalten und einer Zeile:

Benennung deBenennung ruWortartAspekt
kochen
schweißen
варить / сварить,
кипеть / вскипеть,
готовить / приготовить,
заваривать / заварить
сваривать oder варить / сварить
vi, vtipf, pf

Datenbankversion 0

Mit der in Datenbankversion 0 gezeigten Anlage können weder wir noch eine Datenbankanwendung etwas anfangen – die Präsentation ist, um nur zwei Fehler zu nennen, benennungsorientiert und nichtelementar.

Für Sicherstellung von Praxistauglichkeit einer Datenbasis gibt es eine Systematik, die wir Normalisierung nennen. Eine solche Normalisierung erfolgt i. d. R. in drei Etappen, und zwar durch die schrittweise Herstellung der jeweils höheren Normalform.

Erste Normalform: Atomizität

Die erste Normalform liegt vor, wenn …

  1. die Datensätze atomisch sind und
  2. ein eindeutiger Primärschlüssel1 vorhanden ist.

Beide Forderungen werden von Datenbankversion 0 verfehlt. Die Werte aller Attribute sind teilbar, also nicht atomisch. Leider haben wir auch keinen Schlüsselkandidaten, wir müssen also ein geeignetes Attribut anlegen (ID):

IDBenennung deBenennung ruWortartAspekt
1kochenваритьvtipf
2kochenсваритьvtpf
3kochenкипетьviipf
4kochenвскипетьvipf
5kochenготовитьviipf
6kochenприготовитьvipf
7kochenготовитьvtipf
8kochenзаваривать vtipf
9kochenзаваритьvtpf
10schweißenваритьvtipf
11schweißenсваритьvtpf
12schweißenсвариватьvtipf

Datenbankversion 1

Die Werte aller Attribute sind nun atomisch, und wir haben mit ID einen eindeutigen Primärschlüssel. Was wir immer noch nicht haben, ist eine begriffsorientierte Anlage – diese ist bei der gegebenen Anlage strukturell noch nicht möglich.

Die erste Normalform muss vorliegen, damit eine Datenbank abgefragt werden kann. (Wir erinnern uns an Datenbankversion 0, wo wir nicht nach transitiven oder imperfektiven Verben suchen konnten.)

Zweite Normalform: Nur, was zusammengehört

Die zweite Normalform liegt vor, wenn zwei Bedingungen vorliegen:

  1. Die erste Normalform liegt vor.
  2. Jedes Nichtschlüsselattribut ist von jedem Schlüsselkandidaten voll funktional abhängig.

Die zweite Normalform stellt Redundanzfreiheit her, beugt also Inkonsistenzen vor. Mit der Einschränkung „Nichtschlüsselattribut“ in der zweiten Bedingung nehmen wir Fremdschlüssel aus dieser Regel aus. Die dürfen also in der Relation mehrmals auftauchen.

Um die zweite Normalform zu erreichen, haben wir noch ein gutes Stück vor uns:

  • zwischen Begriffen und Benennungen existiert keine (voll) funktionale Abhängigkeit (Synonymie, Polysemie, Homonymie)
  • zwischen Begriffen und Sprachen existiert keine (voll) funktionale Abhängigkeit (nicht jedes Wort ist eine Realie)
  • zwischen Benennungen und Sprachen existiert keine (voll) funktionale Abhängigkeit (deutlich beispielsweise in den Naturwissenschaften oder in der Werbesprache  CO2  технология Intel® vPro™)
  • zwischen Benennungen und Wortarten existiert keine (voll) funktionale Abhängigkeit (Lexeme wie готовить oder kochen können vi und vt sein)
  • zwischen Benennungen und Aspekten existiert keine (voll) funktionale Abhängigkeit (es gibt auch zweiaspektige Benennungen)

Dabei finden wir die folgenden Beziehungen vor (Kardinalitäten):

Begriff-Benennungn:m
Benennung-Wortartn:m
Benennung-Sprachen:m
Benennung-Aspektn:m

Unsere Aufgabe besteht nun darin,. …

  1. nicht (voll) funktional abhängige Attribute in separate Relationen auszulagern
  2. die Beziehungen zwischen den Relationen aufzulösen, ebenfalls in separaten Tabellen.

Datenbankversion 2:

IDBegriff
1kochen (etwas zubereiten)
2kochen (sprudeln)
3kochen (Koch sein)
4kochen (aufbrühen)
5schweißen (Metall)
Relation Begriffe
IDBenennung
1варить
2сварить
3кипеть
4вскипеть
5готовить
6приготовить
7заваривать
8заварить
9kochen
10schweißen
11сваривать
Relation Benennungen
IDWortart
1vi
2vt
Relation Wortarten
IDSprache
1de
2ru
Relation Sprachen
IDAspekt
1ipf
2pf
Relation Aspekte
Begriff-
ID
Benennung-
ID
19
29
39
49
11
12
15
16
23
24
35
47
48
510
51
52
511
Auflösungstabelle
Begriff-Benennung
Benennung-
ID
Wortart-
ID
12
22
31
41
51
52
61
72
82
91
92
101
102
112
Auflösungstabelle
Benennung-Wortart
Benennung-
ID
Sprache-
ID
12
22
32
42
52
62
72
82
91
101
112
Auflösungstabelle
Benennung-Sprache
Benennung-
ID
Aspekt-
ID
11
22
31
42
52
62
71
82
111
Auflösungstabelle
Benennung-Aspekt

Mit der zweiten Normalform haben wir nun eine voll funktionale Abhängigkeit zwischen allen Nichtschlüsselattributen und allen Schlüsselkandidaten und damit auch erstmals die Möglichkeit einer begriffsorientierten Anlage (realisiert in der Relation Begriffe).

Dritte Normalform: Wider die Grüppchenbildung

Während wir in der zweiten Normalform eine direkte Abhängigkeit zur Bedingung für den Verbleib in der Relation gemacht haben, schließen wir in der dritten Normalform nun noch eine indirekte Abhängigkeit aus. Die dritte Normalform liegt vor, wenn …

  1. die zweite Normalform vorliegt und
  2. kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidaten abhängt.

Da wir nur ein Nichtschlüsselattribut pro Relation haben, ist die dritte Normalform in Datenbankversion 2 automatisch erreicht. Der Rest – also wie aus diesem Haufen an Tabellen eine brauchbare Darstellung entsteht – ist eine Frage der Datenabfrage und ‑zusammenstellung, also Aufgabe der Datenbankanwendung.

Quellen

Arntz, Reiner et al. (2014): Einführung in die Terminologiearbeit. Hildesheim: Georg Olms

Schüßler, Hanna (2012): „Wer suchet, der findet?“. Die Vermittlung von Internetrecherchekompetenz in der Übersetzerausbildung. Hamburg: Dr. Kovac

BDÜ (Hrsg.)(2005): Terminologie und Lexikographie. Bern: BDÜ-Fachverlag

Arntz, Reiner et al (2004): Einführung in die Terminologiearbeit. Hildesheim: Georg Olms

Mayer, Felix (1998): Eintragsmodelle für terminologische Datenbanken. Tübingen: Gunter Narr Verlag Tübingen

Heid, U. / Freibott, G. (1990): „Terminological and Lexical Knowledge for Computer-Aided Translation and Technical Wrtiting“. Czap, H. / Nedobity, W. (Hrsg.)(1990): Terminology and Knowledge Engineering – TKE'90. Frankfurt: Indeks-Verlag. 522-535

Hohnhold, Ingo (1990): Übersetzungsorientierte Terminologiearbeit: eine Grundlegung für Praktiker. Stuttgart: InTra

Konferenz der Übersetzungsdienste westeuropäischer Staaten; Arbeitsgruppe Terminologie und Dokumentation KÜWES (Hrsg.)(1990): Empfehlungen für die Terminologiearbeit. Recommendations for Terminology Work. Bern: Schweizerische Bundeskanzlei

Sager, J. C. (1990): A practical course in terminology processing. Amsterdam, Philadelphia: John Benjamins

Budin, Gerhard / Felber, Helmut (1989): Terminologie in Theorie und Praxis. Tübingen: Gunter Narr

Mossmann, Yvan (1988): „Die Terminologiedatenbank vor der Entscheidung: Was ist zu fordern?“. Krollmann, Friedrich / Werner, Reinhold (Hrsg.)(1988): Lebende Sprachen 33. Berlin, New York: De Gruyter. 1-10 und 57-62

Internationales Informationszentrum für Terminologie / International Information Centre for Terminology INFOTERM (1988): Richtlinien für die konventionelle und computerunterstützte übersetzungsorientierte Terminologiearbeit. Entwurf. Wien: De Gruyter. 1-10 und 57-62

International Information Centre for Terminology INFOTERM: „Links and Resources on Terminology Policies and Planning“. [22.04.2020]

ÖNORM 2710 (1993): Übersetzungsorientierte Terminographie. Terminographische Datenkategorien und Richtlinien für ihre Anwendung. Entwurf. Wien.


1Hier hat es sich bewährt, einen numerischen Wert zu nehmen, etwa eine Abteilungs- oder Kundennummer. Fehlt ein geeigneter Kandidat in der Datenbank (wie in unserem Fall), so setzt man i. d. R. eine ID

Kontakt, Impressum, Datenschutzerklärung

Bitte beachten Sie die aktuelle Informationen zum Umgang mit dem Virus COVID-19 („Coronavirus“).
noch eine Informationsseite
noch eine Informationsseite
noch eine Informationsseite
Laut Mitteilung des Rektorats vom 20. März müssen alle Fälle einer Corona-Erkrankung oder ‑Quarantäne auch unter Studierenden an corona@uni-leipzig.de gemeldet werden.