Path: utzoo!attcan!uunet!mcvax!cernvax!unizh!draxler
From: draxler@unizh.UUCP (draxler)
Newsgroups: comp.lang.prolog
Subject: set predicates for db-access
Keywords: prolog, database, set predicates
Message-ID: <303@unizh.UUCP>
Date: 10 Aug 89 12:07:38 GMT
Sender: 
Reply-To: draxler@ifi.unizh.ch
Organization: Inst. fuer Informatik, Univ. Zuerich, Switzerland
Lines: 196


Could anybody spare a second and have a look at what has been keeping
me busy for the last few weeks...

Question:
  Does it make sense to use Prolog's all solutions set predicates as
  database predicates to access external relational database systems?

The idea to use set predicates for that purpose struck me after having
read some papers concerning the coupling of a logic programming
language with relational databases.

In these papers I saw various approaches to such a coupling. Using
Bocca's terminology, the systems that have been implemented either
use
   - loose logical and physical (PROSQL of Walker and Chang),
   - tight logical and physical (work of Nussbaum of ETH Zurich) or
   - tight physical and a combination of loose and tight logical
     (DedGin* of L. Vielle).
coupling.

These systems either rely on Prolog's tuple-at-a-time access method or
implement a completely new logic language that handles sets. In the
first case we have the well-known impedance mismatch between relations
and tuples, in the second case there is usually some loss of generality
in either the database system or the logic language. Furthermore the
effort to change the access method to handle sets is considerable.

On the other hand, if Prolog's set predicates were modified slightly, 
then we would have standard Prolog coupled with a standard relational
database system in an elegant and efficient way. 

The modifications are transparent to the Prolog programmer - findall, bagof
and setof will not change their behaviour. 
The set predicates must be changed in such way that they are able to tell 
whether a fact that is searched for is in the internal Prolog workspace or
not. If it is, the set predicate is evaluated as usual. If it isn't, then
a database query is generated and transmitted to the database system.
In either case the list of instantiated terms in the set predicates 
contains the data we were looking for.

Does such an approach make sense? Where are the problems that I have
overseen?

All contributions to the above questions are welcome, pointers to
related work as well.

Oh yes, I almost forgot: My name is Christoph Draxler and I am a PhD student
at the Department of Computer Science at Zurich University. I am currently
working in the field of logic programming and databases, which explains my
interest...

e-mail: draxler@ifi.unizh.ch
regular mail: Christoph Draxler
	      Institut fuer Informatik
	      Winterthurer Str. 190
	      CH - 8057 Zuerich
	      Tel: ++41/1/257 4335
Newsgroups: Comp.lang.prolog
Subject: set predicates for db-access
Expires: 
References: 
Sender: 
Reply-To: draxler@ifi.unizh.ch
Followup-To: 
Distribution: 
Organization: University of Zurich, Dept. of Computer Science
Keywords: prolog, database, set predicates


Could anybody spare a second and have a look at what has been keeping
me busy for the last few weeks...

Question:
  Does it make sense to use Prolog's all solutions set predicates as
  database predicates to access external relational database systems?

The idea to use set predicates for that purpose struck me after having
read some papers concerning the coupling of a logic programming
language with relational databases.

In these papers I saw various approaches to such a coupling. Using
Bocca's terminology, the systems that have been implemented either
use
   - loose logical and physical (PROSQL of Walker and Chang),
   - tight logical and physical (work of Nussbaum of ETH Zurich) or
   - tight physical and a combination of loose and tight logical
     (DedGin* of L. Vielle).
coupling.

These systems either rely on Prolog's tuple-at-a-time access method or
implement a completely new logic language that handles sets. In the
first case we have the well-known impedance mismatch between relations
and tuples, in the second case there is usually some loss of generality
in either the database system or the logic language. Furthermore the
effort to change the access method to handle sets is considerable.

On the other hand, if Prolog's set predicates were modified slightly, 
then we would have standard Prolog coupled with a standard relational
database system in an elegant and efficient way. 

The modifications are transparent to the Prolog programmer - findall, bagof
and setof will not change their behaviour. 
The set predicates must be changed in such way that they are able to tell 
whether a fact that is searched for is in the internal Prolog workspace or
not. If it is, the set predicate is evaluated as usual. If it isn't, then
a database query is generated and transmitted to the database system.
In either case the list of instantiated terms in the set predicates 
contains the data we were looking for.

Does such an approach make sense? Where are the problems that I have
overseen?

All contributions to the above questions are welcome, pointers to
related work as well.

Oh yes, I almost forgot: My name is Christoph Draxler and I am a PhD student
at the Department of Computer Science at Zurich University. I am currently
working in the field of logic programming and databases, which explains my
interest...

e-mail: draxler@ifi.unizh.ch
regular mail: Christoph Draxler
	      Institut fuer Informatik
	      Winterthurer Str. 190
	      CH - 8057 Zuerich
	      Tel: ++41/1/257 4335
Newsgroups: Comp.lang.prolog
Subject: set predicates for db_access
Expires: 
References: 
Sender: 
Reply-To: draxler@ifi.unizh.ch
Followup-To: 
Distribution: 
Organization: University of Zurich, Dept. of Computer Science
Keywords: prolog, database, set predicates


Could anybody spare a second and have a look at what has been keeping
me busy for the last few weeks...

Question:
  Does it make sense to use Prolog's all solutions set predicates as
  database predicates to access external relational database systems?

The idea to use set predicates for that purpose struck me after having
read some papers concerning the coupling of a logic programming
language with relational databases.

In these papers I saw various approaches to such a coupling. Using
Bocca's terminology, the systems that have been implemented either
use
   - loose logical and physical (PROSQL of Walker and Chang),
   - tight logical and physical (work of Nussbaum of ETH Zurich) or
   - tight physical and a combination of loose and tight logical
     (DedGin* of L. Vielle).
coupling.

These systems either rely on Prolog's tuple-at-a-time access method or
implement a completely new logic language that handles sets. In the
first case we have the well-known impedance mismatch between relations
and tuples, in the second case there is usually some loss of generality
in either the database system or the logic language. Furthermore the
effort to change the access method to handle sets is considerable.

On the other hand, if Prolog's set predicates were modified slightly, 
then we would have standard Prolog coupled with a standard relational
database system in an elegant and efficient way. 

The modifications are transparent to the Prolog programmer - findall, bagof
and setof will not change their behaviour. 
The set predicates must be changed in such way that they are able to tell 
whether a fact that is searched for is in the internal Prolog workspace or
not. If it is, the set predicate is evaluated as usual. If it isn't, then
a database query is generated and transmitted to the database system.
In either case the list of instantiated terms in the set predicates 
contains the data we were looking for.

Does such an approach make sense? Where are the problems that I have
overseen?

All contributions to the above questions are welcome, pointers to
related work as well.

Oh yes, I almost forgot: My name is Christoph Draxler and I am a PhD student
at the Department of Computer Science at Zurich University. I am currently
working in the field of logic programming and databases, which explains my
interest...

e-mail: draxler@ifi.unizh.ch
regular mail: Christoph Draxler
	      Institut fuer Informatik
	      Winterthurer Str. 190
	      CH - 8057 Zuerich
	      Tel: ++41/1/257 4335