10.07.2015 Aufrufe

Defaults in deduktiven Datenbanken

Defaults in deduktiven Datenbanken

Defaults in deduktiven Datenbanken

MEHR ANZEIGEN
WENIGER ANZEIGEN

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.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!