A Type Language for Calendars

Time and calendars play an important role in databases, on the Semantic Web, as well as in mobile computing. Temporal data and calendars require (specific) modeling and processing tools. CaTTS is a type language for calendar definitions using which one can model and process temporal and calendric data. CaTTS is based on a "theory reasoning" approach for efficiency reasons. This article addresses type checking temporal and calendric data and constraints. A thesis underlying CaTTS is that types and type checking are as useful and desirable with calendric data types as with other data types. Types enable (meaningful) annotation of data. Type checking enhances efficiency and consistency of programming and modeling languages like database and Web query languages

Functorial Data Migration

In this paper we present a simple database definition language: that of categories and functors. A database schema is a small category and an instance is a set-valued functor on it. We show that morphisms of schemas induce three "data migration functors", which translate instances from one schema to the other in canonical ways. These functors parameterize projections, unions, and joins over all tables simultaneously and can be used in place of conjunctive and disjunctive queries. We also show how to connect a database and a functional programming language by introducing a functorial connection between the schema and the category of types for that language. We begin the paper with a multitude of examples to motivate the definitions, and near the end we provide a dictionary whereby one can translate database concepts into category-theoretic concepts and vice-versa.Comment: 30 page

Functions as types or the "Hoare logic" of functional dependencies

Inspired by the trend on unifying theories of programming, this paper shows how the algebraic treatment of standard data dependency theory equips relational data with functional types and an associated type system which is useful for type checking database operations and for query optimization. Such a typed approach to database programming is then shown to be of the same family as other programming logics such as eg. Hoare logic or that of strongest invariant functions which has been used in the analysis of while statements. The prospect of using automated deduction systems such as Prover9 for type-checking and query optimization on top of such an algebraic approach is considered.Fundação para a Ciência e a Tecnologia (FCT

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]

Database Programming in Machiavelli - A Polymorphic Language With Static Type Inference

Machiavelli is a polymorphically typed programming language in the spirit of ML, but supports a different type inferencing that makes its polymorphism somewhat more general than that of ML and appropriate for database applications. In particular, a function that selects a field f of a records is polymorphic in the sense that it can be applied to any record which contains a field f with the appropriate type. When combined with a set data type and database operations including join and projection, this provides a natural medium for relational database programming. Moreover, by implementing database objects as reference types and generating the appropriate views - sets of structures with identity - we can achieve a degree of static type checking for object-oriented databases

DAS: a data management system for instrument tests and operations

The Data Access System (DAS) is a metadata and data management software system, providing a reusable solution for the storage of data acquired both from telescopes and auxiliary data sources during the instrument development phases and operations. It is part of the Customizable Instrument WorkStation system (CIWS-FW), a framework for the storage, processing and quick-look at the data acquired from scientific instruments. The DAS provides a data access layer mainly targeted to software applications: quick-look displays, pre-processing pipelines and scientific workflows. It is logically organized in three main components: an intuitive and compact Data Definition Language (DAS DDL) in XML format, aimed for user-defined data types; an Application Programming Interface (DAS API), automatically adding classes and methods supporting the DDL data types, and providing an object-oriented query language; a data management component, which maps the metadata of the DDL data types in a relational Data Base Management System (DBMS), and stores the data in a shared (network) file system. With the DAS DDL, developers define the data model for a particular project, specifying for each data type the metadata attributes, the data format and layout (if applicable), and named references to related or aggregated data types. Together with the DDL user-defined data types, the DAS API acts as the only interface to store, query and retrieve the metadata and data in the DAS system, providing both an abstract interface and a data model specific one in C, C++ and Python. The mapping of metadata in the back-end database is automatic and supports several relational DBMSs, including MySQL, Oracle and PostgreSQL.Comment: Accepted for pubblication on ADASS Conference Serie

Polymorphism and Type Inference in Database Programming

The polymorphic type system of ML can be extended in two ways that make it appropriate as the basis of a database programming language. The first is an extension to the language of types that captures the polymorphic nature of field selection; the second is a technique that generalizes relational operators to arbitrary data structures. The combination provides a statically typed language in which relational databases may be cleanly represented as typed structures. As in ML types are inferred, which relieves the programmer of making the rather complicated type assertions that may be required to express the most general type of a program that involves field selection and generalized relational operators. It is also possible to use these ideas to implement various aspects of object-oriented databases. By implementing database objects as reference types and generating the appropriate views - sets of structures with identity - we can achieve a degree of static type checking for object-oriented databases. Moreover it is possible to exploit the type system to check the consistency of object-oriented classes (abstract data types with inheritance). A prototype language based on these ideas has been implemented. While it lacks some important practical features, it demonstrates that a wide variety of database structures can be cleanly represented in a polymorphic programming language

Galileo: A strongly typed, interactive conceptual language

ABSTRACT Galileo, a programming language for database applications, is presented. Galileo is a strongly typed, interactive programming language designed specifically to support Semantic Data Model features (classification, aggregation and specialization) as well as abstraction mechanisms of modern programming languages (types, abstract types and modularization). The main contributions of Galileo are: a) the proposal of a flexible type system to model database structure and semantic integrity constraints; b) the inclusion of type hierarchies to support the specialization abstraction mechanism of Semantic Data Models. c) the proposal of a modularization mechanism to structure data and operations into interrelated units; d) the integration of the abstraction mechanisms into an expression based language that allows an interactive use of the database without resorting to a new stand alone query language. Galileo will be used in the immediate future as a tool for database design and, in the long term, as a high level interface for DBMSs