Defaults in deduktiven Datenbanken
Defaults in deduktiven Datenbanken
Defaults in deduktiven Datenbanken
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
4 KAPITEL 1. EINFÜHRUNGNicht-Logiker. Es ist etwa naheliegend, e<strong>in</strong>e Tabelle als Menge von Fakten zu notieren:bestellung(meier, taschenlampe).bestellung(schmidt, radio).bestellung(schmidt, batterien).Angenommen, man fragt nun nach den Kunden, die e<strong>in</strong>e Taschenlampe, aber ke<strong>in</strong>e Batterienbestellt haben:bestellung(X, taschenlampe) ∧ ¬bestellung(X, batterien).Logisch gesehen würde diese Aussage für X = meier nicht folgen. Dazu müßte manerst spezifizieren, daß die explizit angegebenen Tupel die e<strong>in</strong>zigen s<strong>in</strong>d, also das positiveWissen über die Tabelle vollständig ist.Natürlich kann man das <strong>in</strong> der Logik formulieren, es ist nur etwas komplizierter:bestellung(X, Y ) ↔ X = meier ∧ Y = taschenlampe∨ X = schmidt ∧ Y = radio∨ X = schmidt ∧ Y = batterien.Diese Formulierung ist allerd<strong>in</strong>gs tatsächlich noch nicht ausreichend. Man muß erst nochangeben, daß je zwei verschiedene Namen auch verschiedene Objekte bezeichnen, also daßetwameier ≠ schmidt.Dies ist, obwohl pr<strong>in</strong>zipiell möglich, doch praktisch etwas mühsam (die Anzahl der Formelndieser Art wächst quadratisch <strong>in</strong> der Anzahl der Konstanten).Natürlich könnte man Abkürzungen verwenden. Die e<strong>in</strong>fachste Abkürzung wäre wohl,für alle nicht explizit genannten Paare von Kunden und Waren die entsprechende Negationzu ergänzen, also z.B.¬bestellung(meier, batterien).Aber das wäre ja gerade wieder e<strong>in</strong> Default.Warum sollten <strong>Defaults</strong> explizit spezifiziert werden?Nachdem man sich von der Nützlichkeit der Negations-<strong>Defaults</strong> überzeugt hat, könnteman sie natürlich e<strong>in</strong>fach fest <strong>in</strong> den Antwortalgorithmus e<strong>in</strong>bauen (das ist die momentanübliche Lösung). Allerd<strong>in</strong>gs ist die genaue Semantik nicht mehr so klar, wenn man denBereich der Hornklauseln verläßt. Es reicht dann nämlich nicht mehr aus, e<strong>in</strong>fach dieNegation jedes nicht implizierten Faktums anzunehmen. Dies würde zu Widersprüchenführen [Rei78]. E<strong>in</strong> Beispiel istkann fliegen(X) ← vogel(X) ∧ ¬ausnahme(X).vogel(tweety).Hier folgt weder kann fliegen(tweety) (tweety könnte e<strong>in</strong>e Ausnahme se<strong>in</strong>, beispielsweisee<strong>in</strong> P<strong>in</strong>gu<strong>in</strong>) noch ausnahme(tweety) (darüber ist <strong>in</strong> der Datenbank nichts gesagt). Trotzdemkann man nicht gleichzeitig ¬kann fliegen(tweety) und ¬ausnahme(tweety) annehmen,denn dies widerspricht der angegebenen Regel.