Strong types for relational databases: functional pearl

Haskell's type system with multi-parameter constructor classes and functional dependencies allows static (compile-time) computations to be expressed by logic programming on the level of types. This emergent capability has been exploited for instance to model arbitrary-length tuples (heterogeneous lists), extensible records, functions with variable length argument lists, and (homogenous) lists of statically fixed length (vectors).We explain how type-level programming can be exploited to define a strongly-typed model of relational databases and operations on them. In particular, we present a strongly typed embedding of a significant subset of SQL in Haskell. In this model, meta-data is represented by type-level entities that guard the semantic correctness of database operations at compile time.Apart from the standard relational database operations, such as selection and join, we model functional dependencies (among table attributes), normal forms, and operations for database transformation. We show how functional dependency information can be represented at the type level, and can be transported through operations. This means that type inference statically computes functional dependencies on the result from those on the arguments.Our model shows that Haskell can be used to design and prototype typed languages for designing, programming, and transforming relational databasesFundação para a Ciência e a Tecnologia (FCT) - POSI/ICHS/44304/2002; SFRH/BPD/11609/2002

Converting relational databases into object relational databases

This paper proposes an approach for migrating existing Relational DataBases (RDBs) into Object-Relational DataBases (ORDBs). The approach is superior to existing proposals as it can generate not only the target schema but also the data instances. The solution takes an existing RDB as input, enriches its metadata representation with required semantics, and generates an enhanced canonical data model, which captures essential characteristics of the target ORDB, and is suitable for migration. A prototype has been developed, which migrates successfully RDBs into ORDBs (Oracle 11g) based on the canonical model. The experimental results were very encouraging, demonstrating that the proposed approach is feasible, efficient and correct

Learning from AI : new trends in database technology

Recently some researchers in the areas of database data modelling and knowledge representations in artificial intelligence have recognized that they share many common goals. In this survey paper we show the relationship between database and artificial intelligence research. We show that there has been a tendency for data models to incorporate more modelling techniques developed for knowledge representations in artificial intelligence as the desire to incorporate more application oriented semantics, user friendliness, and flexibility has increased. Increasing the semantics of the representation is the key to capturing the "reality" of the database environment, increasing user friendliness, and facilitating the support of multiple, possibly conflicting, user views of the information contained in a database

Creating a Relational Distributed Object Store

In and of itself, data storage has apparent business utility. But when we can convert data to information, the utility of stored data increases dramatically. It is the layering of relation atop the data mass that is the engine for such conversion. Frank relation amongst discrete objects sporadically ingested is rare, making the process of synthesizing such relation all the more challenging, but the challenge must be met if we are ever to see an equivalent business value for unstructured data as we already have with structured data. This paper describes a novel construct, referred to as a relational distributed object store (RDOS), that seeks to solve the twin problems of how to persistently and reliably store petabytes of unstructured data while simultaneously creating and persisting relations amongst billions of objects.Comment: 12 pages, 5 figure

Automating Fine Concurrency Control in Object-Oriented Databases

Several propositions were done to provide adapted concurrency control to object-oriented databases. However, most of these proposals miss the fact that considering solely read and write access modes on instances may lead to less parallelism than in relational databases! This paper cope with that issue, and advantages are numerous: (1) commutativity of methods is determined a priori and automatically by the compiler, without measurable overhead, (2) run-time checking of commutativity is as efficient as for compatibility, (3) inverse operations need not be specified for recovery, (4) this scheme does not preclude more sophisticated approaches, and, last but not least, (5) relational and object-oriented concurrency control schemes with read and write access modes are subsumed under this proposition

Conditions for interoperability

Interoperability for information systems remains a challenge both at the semantic and organisational levels. The original three-level architecture for local databases needs to be replaced by a categorical four-level one based on concepts, constructions, schema types and data together with the mappings between them. Such an architecture provides natural closure as further levels are superfluous even in a global environment. The architecture is traversed by means of the Godement calculus: arrows may be composed at any level as well as across levles. The necessary and sufficient conditions for interoperability are satisfied by composable (formal) diagrams both for intension and extension in categories that are cartesian closed and locally cartesian closed. Methods like partial categories and sketches in schema design can benefit from Freyd’s punctured diagrams to identify precisely type-forcing natural transformations. Closure is better achieved in standard full categories. Global interoperability of extension can be achieved through semantic annotation but only if applied at run time

UML Class Diagram or Entity Relationship Diagram : An Object Relational Impedance Mismatch

It is now nearly 30 years since Peter Chen’s watershed paper “The Entity-Relationship Model –towards a Unified View of Data”. [1] The entity relationship model and variations and extensions to ithave been taught in colleges and universities for many years. In his original paper Peter Chen looked at converting his new ER model to the then existing data structure diagrams for the Network model. In recent years there has been a tendency to use a Unified Modelling Language (UML) class diagram forconceptual modeling for relational databases, and several popular course text books use UMLnotation to some degree [2] [3]. However Object and Relational technology are based on different paradigms. In the paper we argue that the UML class diagram is more of a logical model (implementation specific). ER Diagrams on theother hand, are at a conceptual level of database design dealing with the main items and their relationships and not with implementation specific detail. UML focuses on OOAD (Object Oriented Analysis and Design) and is navigational and program dependent whereas the relational model is set based and exhibits data independence. The ER model provides a well-established set of mapping rules for mapping to a relational model. In this paper we look specifically at the areas which can cause problems for the novice databasedesigner due to this conceptual mismatch of two different paradigms. Firstly, transferring the mapping of a weak entity from an Entity Relationship model to UML and secondly the representation of structural constraints between objects. We look at the mixture of notations which students mistakenly use when modeling. This is often the result of different notations being used on different courses throughout their degree. Several of the popular text books at the moment use either a variation of ER,UML, or both for teaching database modeling. At the moment if a student picks up a text book they could be faced with either; one of the many ER variations, UML, UML and a variation of ER both covered separately, or UML and ER merged together. We regard this problem as a conceptual impedance mismatch. This problem is documented in [21] who have produced a catalogue of impedance mismatch problems between object-relational and relational paradigms. We regard the problems of using UML class diagrams for relational database design as a conceptual impedance mismatch as the Entity Relationship model does not have the structures in the model to deal with Object Oriented concepts Keywords: EERD, UML Class Diagram, Relational Database Design, Structural Constraints, relational and object database impedance mismatch. The ER model was originally put forward by Chen [1] and subsequently extensions have been added to add further semantics to the original model; mainly the concepts of specialisation, generalisation and aggregation. In this paper we refer to an Entity-Relationship model (ER) as the basic model and an extended or enhanced entity-relationship model (EER) as a model which includes the extra concepts. The ER and EER models are also often used to aid communication between the designer and the user at the requirements analysis stage. In this paper when we use the term “conceptual model” we mean a model that is not implementation specific.ISBN: 978-84-616-3847-5 3594Peer reviewe