draxler@unizh.UUCP (draxler) (08/10/89)
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 4335jbeard@quintus.UUCP (Jeff Beard) (08/12/89)
Article 1533 of comp.lang.prolog: >From: draxler@unizh.UUCP (draxler) Posted: Thu Aug 10 15:02:25 1989 > > Question: > Does it make sense to use Prolog's all solutions set predicates as > database predicates to access external relational database systems? > > These systems either rely on Prolog's tuple-at-a-time access method or > implement a completely new logic language that handles sets. > > 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? First, accessing a commercial DBMS of some enterprise may entail tables containing tens of thousands of tuples. Imagine the table CustInfo of the phone company or the U.S library of congress BooksOnHand. To attempt to retrieve and instantiate the solution set per se is begging to overflow available memory. Second, there is a real time/space cost to each solution set so retrieved and the higher level logic (as in a browser) may well need very few tuples prior to aborting the query. The cost per useful tuple can be extream. For this and other reasons, the Quintus Prolog Database Interface defines relational predicates as the specification of: The db/3 facts define a specific relational interface. db(TableName, DbName, Predname) and As an example, the following db/3 facts define Prolog relations item/7, customer/7, and order/3. db('ITEM', tutorial, item( 'Serial_Number':integer , 'Model_Number':integer, 'Manufacturer_ID':integer, 'Acquisition_Date':integer, 'Sales_Price':integer, 'Order_Number':integer, 'Purchase_Price':integer )). db('Customer', tutorial, customer('Customer_Number':integer, 'Name':string, 'Address':string, 'City':string, 'State':string, 'Zip_Code':string, 'Phone_Number':string )). db('orders', tutorial, order( 'Order_Number':integer, 'Date_Ordered':integer, 'Customer_Number':integer )). when a db_connect(DbName) is encountered, the connection is made, the schema retrieved for each db/3 and the predicate implied (item/7,customer/7, and order/3) are built. When such a relational predicate is called, eg orders(Onum,Odate,CuNum). the requisite SQL is generated and the first projection of orders(Onum,Odate,CuNum) is instantiated. The normal Prolog backtacking mechanics will provide additional members of the solution set until no more are available, which returns an order/3 fail. With such a primative, Prolog conjuctions can be transformed into SQL JOINs, with the work being performed by the external DBMS rather than in Prolog. eg: (read _* as anonymous variable of dis-interest) orders(Onum,Odate,CuNum), item(_Serial,_Model,_Mfg,_Ad,Price,Onum,WholeSale). will produce a join of 'ITEM' to 'orders' on field 'Order_Number' and the projected results of Onum,Odate,CuNum,Price,WholeSale.
kam@druhi.ATT.COM (Karen A. Morrissey) (08/17/89)
About 3-4 years ago, we bolted together C-Prolog 1.5 and 2 different proprietary relational database managers. Programmers could define predicates that mapped to relations as if a relation was a collection of grounded unit clauses. We even handled transaction processing (commit and abort). The interface was transparent except for the unsurprising temporal problems with additions and deletions. In practice it worked just fine. Karen Morrissey AT&T Bell Labs 303-538-4587 att!druhi!kam