On Compiling Logic Programs Into Relational Algebra

The combination of logic programming methods and database systems technology will result in knowledge bases of increased size and improved efficiency: this topic has received a lot of attention [Zaniolo 1985, Reiter 1978, Chang 1986, Minker 1978, Henschen 1984, Parker 1986, Brodie 1986]. Our approach to integrating logic programming languages (e. g. PROLOG) and database systems is to compile logic programming languages into conventional relational algebra. There are many technical problems which must be addressed and solved when compiling logic programs into relational algebra. Mainly, we are interested in the following problems: the finiteness (i. e. safety) of a logic program's executions and the differences between logic programing languages and database systems in data representation and typing systems. Our approach to safety checking integrates the rule/goal graph of [Ullman 1985] with the magic basis of a variable [Zaniolo 1986]. This approach allows us, effectively, to check the safety of a logic program at compile time, for those programs which are strongly safe. Otherwise, the safety of the program with respect to a query must be checked at execution time. Relational database systems are well typed, whilst logic programming languages are not. We overcome this difference by adding types to PROLOG (i. e TPROLOG). TPROLOG allows the user to define enumerated types, sub-types, structured types, and variant types. Our approach to compiling typed logic programs into conventional relational algebra expressions is to translate the logic program containing complex clauses into an equivalent complex-free program, and then to translate it into a form suitable for storage and manipulation by conventional relational database systems. The normalization of logic programs is achieved by removing complex arguments from facts and rules and replacing them with simplified (i. e. normalized) facts and rules. The normalized facts are stored in a conventional relational database (i. e. extensional database), and the normalized rules are stored in a rule base (i. e. intentional database). The translation of a complex-free program into conventional relational algebra is based on [Reiter 1978, Chang 1986, Henschen 1984, Bancilhon 1986]

Introducing new constructs for data modelling and column generation in LP modelling languages

Through popular implementation of structured query language (SQL) and query-by-example(QBE) relational databases have become the de-facto industry standard for data modelling.We consider the indices, sets, and the declarative form of Linear Programming (LP) modelling languages and introduce new constructs which provide direct link to the database systems. The models constructed in this way are data driven and display a dynamicstructure. We then show how this approach can be naturally extended to include column generation features stated in procedural forms within an otherwise declarative modelling paradigm

Semantics of Types for Database Objects

This paper proposes a framework of denotational semantics of database type systems and constructs a type system for complex database objects. Starting with an abstract analysis of the relational model, we develop a mathematical theory for the structures of domains of database objects. Based on this framework, we construct a concrete database type system and its semantic domain. The type system allows arbitrarily complex structures that can be constructed using labeled records, labeled variants, finite sets and recursion. On the semantic domain, in addition to standard operations on records, variants and sets, a join and a projection are available as polymorphically typed computable functions on arbitrarily complex objects. We then show that both the type system and the semantic domain can be uniformly integrated in an ML-like programming language. This leads us to develop a database programming language that supports rich data structures and powerful operations for databases while enjoying desirable features of modern type systems of programming languages including strong static type-checking, static type inference and ML polymorphism

Improved Presentation and Facade Layer Operations for Software Engineering Projects

Nowadays, one of the most challenging situations for software developers is the presence of a mismatch between relational database systems and programming codes. In the literature, this problem is defined as "impedance mismatch". This study is to develop a framework built on innovations based on the existing Object Relational Mapping technique to solve these problems. In the study, users can perform operations for three different database systems such as MsSQL, MySql and Oracle. In addition, these operations can be done within the framework of C# and Java programming languages. In this framework, while the developers can define database tables in the interface automatically, they can create relations between tables by defining a foreign key. When the system performs these operations, it creates tables, views, and stored procedures automatically. In addition, entity classes in C# and Java for tables and views, and operation classes for stored procedures are created automatically. The summary of the transactions can be taken as pdf file by the framework. In addition, the project can automatically create Windows Communication Foundation classes to facilitate the handling of database elements created and the interfacing operations, as well. This framework, which supports distributed systems, can be downloaded at this link

Database Queries that Explain their Work

Provenance for database queries or scientific workflows is often motivated as providing explanation, increasing understanding of the underlying data sources and processes used to compute the query, and reproducibility, the capability to recompute the results on different inputs, possibly specialized to a part of the output. Many provenance systems claim to provide such capabilities; however, most lack formal definitions or guarantees of these properties, while others provide formal guarantees only for relatively limited classes of changes. Building on recent work on provenance traces and slicing for functional programming languages, we introduce a detailed tracing model of provenance for multiset-valued Nested Relational Calculus, define trace slicing algorithms that extract subtraces needed to explain or recompute specific parts of the output, and define query slicing and differencing techniques that support explanation. We state and prove correctness properties for these techniques and present a proof-of-concept implementation in Haskell.Comment: PPDP 201

Data Structures and Data Types in Object-Oriented Databases

The possibility of finding a static type system for object-oriented programming languages was initiated by Cardelli [Car88, CW85] who showed that it is possible to express the polymorphic nature of functions such a