Projektvorschlag: Data Dictionary fuer deduktive Datenbank
==========================================================

- Zunaechst hat man ein Data Dictionary fuer eine normale relationale
  Datenbank, die sogenannten EDB-Praedikate (EDB: "extensional database",
  diese Praedikate sind extensional definiert, naemlich durch Aufzaehlung
  der Tupel).
  Man braucht mindestens den Namen des Praedikates
  und seine Spalten mit Positions-Nummer, Namen, Datentyp.
  Datentypen sind mindestens int, string, float.
  Guenstig waere natuerlich eine erweiterbare Liste.
  Z.B. sind Aufzaehlungstypen in deduktiven Datenbanken haeufig.
  Auch ueber parametrisierte Typen entsprechend NUMERIC(p,s) koennte man
  nachdenken.

- Natuerlich enthaelt eine deduktive Datenbank Regeln.
  Regeln definieren abgeleitete Praedikate
  (IDB-Praedikate, "intensional database").
  Diese entsprechen Sichten und werden in Anfragen eingesetzt.
  Wahrscheinlich wuerde man im Data Dictionary nur die laengerfristig
  definierten Sichten abspeichern.
  Ein System muesste aber auch mit Regeln fuer IDB-Praedikate umgehen,
  die nur fuer eine einzelne Anfrage gebraucht werden.
  Fuer IDB-Praedikate muss mindestens die Anzahl Argumente erfasst werden
  (Stelligkeit). Eine Angabe von Argumentnamen und Datentypen ist optional
  (die Datentypen ergeben sich aus den Regeln).

- Regeln haben einen Kopf und einen Rumpf.
  Der Kopf einhaelt ein einzelnes Literal (genauer: ein positives Literal,
  d.h. eine atomare Formel), der Rumpf eine Liste von Literalen
  (diese koennen positive oder negative Literale sein,
  d.h. atomare Formeln oder negierte atomare Formeln).
  Das Praedikat der atomaren Formel im Kopf muss ein IDB-Praedikat sein,
  im Rumpf koennen dagegen beliebige Praedikate verwendet werden
  (EDB oder IDB).

- Eine atomare Formel besteht aus einem Praedikat und einer Liste
  von Argumenten.
  Argumente koennen Variablen oder Konstanten sein.
  Eine Variable hat einen Namen
  (optional koennte ihr ein berechneter Datentyp zugeordnet sein).
  Konstanten haben eine externe Repraesentation, die ein String ist.
  Sie haben immer einen Typ.
  Man koennte statt der externen Repraesentation auch den Wert speichern
  (ein integer-Wert, ein String, etc.).
  Dann koennte man in der Ausgabe z.B. fuehrende Nullen oder
  Hexadezimalschreibweise nicht mehr wiederherstellen.
  Wenn man die Regeln aber tatsaechlich wieder so ausdrucken wollte,
  wie sie der Programmierer eingegeben hat, muesste man auch Leerplatz
  und Kommentare speichern. Das geht fuer dieses Projekt wohl etwas zu weit.

- Im Rumpf einer Regel koennen eigentlich auch eingebaute Praedikate
  wie etwa < verwendet werden (das ist eine dritte Art von Praedikaten
  neben EDB- und IDB-Praedikaten).
  Welche eingebauten Praedikate moeglich sind, definiert das DBMS.
  Eine Liste waere nuetzlich. Falls das Projekt aber zu gross wird,
  koennte man diesen Punkt auslassen.
  Eingebaute Praedikate koennen nur mit bestimmten Bindungsmustern
  ausgefuehrt werden. Ein Bindungsmuster legt fuer jedes Argument fest,
  ob es "bound" (Eingabe) oder "free" (Ausgabe) ist.
  Typische eingebaute Praedikate haben nur ein moegliches Bindungsmuster,
  z.B. kann < nur ausgefuehrt werden, wenn linke und rechte Seite schon
  bekannt sind, das Bindungsmuster ist also "bb" (Bindungsmuster werden oft
  als String notiert aus den Zeichen "b" fuer "bound" und "f" fuer "free".
  Die Stringlaenge muss mit der Anzahl Argumente uebereinstimmen.
  In Prolog heissen Bindungsmuster "modes" und werden mit "+" (bound),
  "-" (free) und "?" (egal) geschrieben.

- Fuer IDB-Praedikate koennten auch unterstuetzte Bindungsmuster spezifiziert
  werden. Das koennen mehrere sein. Dieser Teil ist auch optional.

- Wenn man noch weiter denkt, koennte man Index-Strukturen fuer die Relationen
  und Auswertungsreihenfolgen fuer die Regeln speichern ...
  Auch die Duplikateliminierung bei den Praedikaten waere interessant.
  Dies wuerde aber wohl alles den Projektrahmen sprengen.