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