Mapping-equivalence and oid-equivalence of single-function object-creating conjunctive queries

Conjunctive database queries have been extended with a mechanism for object creation to capture important applications such as data exchange, data integration, and ontology-based data access. Object creation generates new object identifiers in the result, that do not belong to the set of constants in the source database. The new object identifiers can be also seen as Skolem terms. Hence, object-creating conjunctive queries can also be regarded as restricted second-order tuple-generating dependencies (SO tgds), considered in the data exchange literature. In this paper, we focus on the class of single-function object-creating conjunctive queries, or sifo CQs for short. We give a new characterization for oid-equivalence of sifo CQs that is simpler than the one given by Hull and Yoshikawa and places the problem in the complexity class NP. Our characterization is based on Cohen's equivalence notions for conjunctive queries with multiplicities. We also solve the logical entailment problem for sifo CQs, showing that also this problem belongs to NP. Results by Pichler et al. have shown that logical equivalence for more general classes of SO tgds is either undecidable or decidable with as yet unknown complexity upper bounds.Comment: This revised version has been accepted on 11 January 2016 for publication in The VLDB Journa

Types With Extents: On Transforming and Querying Self-Referential Data-Structures (Dissertation Proposal)

The central theme of this paper is to study the properties and expressive power of data-models which use type systems with extents in order to represent recursive or self-referential data-structures. A standard type system is extended with classes which represent the finite extents of values stored in a database. Such an extended type system expresses constraints about a database instance which go beyond those normally associated with the typing of data-values, and takes on an important part of the functionality of a database schema. Recursion in data-structures is then constrained to be defined via these finite extents, so that all values in a database have a finite representation. The idea of extending a type system with such classes is not new. In particular [2] introduced a type system and data models equivalent to those used here. However such existing work focuses on the expressive power of systems which allow the dynamic creation of recursive values, while we are concerned more with the properties of querying and manipulating databases containing known static extensions of data-values

Functional Dependencies for Object Databases: Motivation and Axiomatization

Object identification by abstract identifiers should be considered as a modeling and not as a database concept. This means that object identifiers are not appropriate for the access to specific objects using a database language. In this paper we discuss how the relational concept of a functional dependency can be adapted to object databases in order to get more convenient ways of accessing objects. Graph based object functional dependencies are proposed as a means to specify constraints between attributes and object types of an object schema. Value based identification criteria can be defined using a special type of object functional dependencies. Different definitions of satisfaction are given for these constraints, based on a so-called validation relation, and their relationships are investigated. These definitions are related to different forms of identification. Using the strongest notion of satisfaction, inference rules for the derivation of new dependencies are discussed with emphasis on the characteristics of rules combining two dependencies, like the transitivity rule. In addition to generalized relational rules further rules are needed, mainly concerned with transition from the object type level to the attribute level and vice versa

Semantics of Database Transformations

Database transformations arise in many different settings including database integrations, evolution of database systems, and implementing user views and data-entry tools. This paper surveys approaches that have been taken to problems in these settings, assesses their strengths and weaknesses, and develops requirements on a formal model for specifying and implementing database transformations. We also consider the problem of insuring the correctness of database transformations. In particular, we demonstrate that the usefulness of correctness conditions such as information preservation are hindered by the interactions of transformations and database constraints, and the limited expressive power of established database constraint languages. We conclude that more general notions of correctness are required, and that there is a need for a uniform formalism for expressing both database transformations and constraints, and reasoning about their interactions. Finally we introduce WOL, a declarative language for specifying and implementing database transformations and constraints. We briefly describe the WOL language and its semantics, and argue that it addresses many of the requirements of a formalism for dealing with general database transformations

Transforming Databases with Recursive Data Structures

This thesis examines the problems of performing structural transformations on databases involving complex data-structures and object-identities, and proposes an approach to specifying and implementing such transformations. We start by looking at various applications of such database transformations, and at some of the more significant work in these areas. In particular we will look at work on transformations in the area of database integration, which has been one of the major motivating areas for this work. We will also look at various notions of correctness that have been proposed for database transformations, and show that the utility of such notions is limited by the dependence of transformations on certain implicit database constraints. We draw attention to the limitations of existing work on transformations, and argue that there is a need for a more general formalism for reasoning about database transformations and constraints. We will also argue that, in order to ensure that database transformations are well-defined and meaningful, it is necessary to understand the information capacity of the data-models being transformed. To this end we give a thorough analysis of the information capacity of data-models supporting object identity, and will show that this is dependent on the operations supported by a query language for comparing object identities. We introduce a declarative language, WOL, based on Horn-clause logic, for specifying database transformations and constraints. We also propose a method of implementing transformations specified in this language, by manipulating their clauses into a normal form which can then be translated into an underlying database programming language. Finally we will present a number of optimizations and techniques necessary in order to build a practical implementation based on these proposals, and will discuss the results of some of the trials that were carried out using a prototype of such a system

Change Management for Distributed Ontologies

Akkermans, J.M. [Promotor]Schreiber, A.T. [Promotor

Aide à l'Évolution Logicielle dans les Organisations

Software systems are now so intrinsically part of our lives that we don't see them any more. They run our phones, our cars, our leisures, our banks, our shops, our cities … This brings a significant burden on the software industry. All these systems need to be updated, corrected, and enhanced as the users and consumers have new needs. As a result, most of the software engineering activity may be classified as Software Maintenance, “the totality of activities required to provide cost-effective support to a software system”.In an ecosystem where processing power for computers, and many other relevant metrics such as disk capacity or network bandwidth, doubles every 18 months (“Moore's Law”), technologies evolve at a fast pace. In this ecosystem, software maintenance suffers from the drawback of having to address the past (past languages, existing systems, old technologies). It is often ill-perceived, and treated as a punishment. Because of this, solutions and tools for software maintenance have long lagged far behind those for new software development. For example, the antique approach of manually inserting traces in the source code to understand the execution path is still a very valid one.All my research activity focused on helping people to do software maintenance in better conditions or more efficiently. An holistic approach of the problem must consider the software that has to be maintained, the people doing it, and the organization in which and for which it is done. As such, I studied different facets of the problem that will be presented in three parts in this document: Software: The source code is the center piece of the maintenance activity. Whatever the task (ex: enhancement or bug correction), it typically comes down to understand the current source code and find out what to change and/or add to make it behave as expected. I studied how to monitor the evolution of the source code, how to prevent it's decaying and how to remedy bad situations; People: One of the fundamental asset of people dealing with maintenance is the knowledge they have, of computer science (programming techniques), of the application domain, of the software itself. It is highly significant that from 40% to 60% of software maintenance time is spent reading the code to understand what it does, how it does it, how it can be changed; Organization: Organizations may have a strong impact on the way activities such as software maintenance are performed by their individual members. The support offered within the organization, the constraints they impose, the cultural environment, all affect how easy or difficult it can be to do the tasks and therefore how well or badly they can be done. I studied some software maintenance processes that organizations use.In this document, the various research topics I addressed, are organized in a logical way that does not always respect the chronological order of events. I wished to highlight, not only the results of the research, through the publications that attest to them, but also the collaborations that made them possible, collaboration with students or fellow researchers. For each result presented here, I tried to summarize as much as possible the discussion of the previous state of the art and the result itself. First because, more details can easily be found in the referenced publications, but also because some of this research is quite old and sometimes fell in the realm of “common sense”.Les systèmes logiciels font maintenant partie intrinsèque de nos vies à tel point que nous ne les voyons plus. Ils pilotent nos téléphones, nos voitures, nos loisirs, nos banques, nos magasins, nos villes, … Cela apporte de lourdes contraintes à l'industrie du logiciel car tous ces systèmes doivent être continuellement mis à jour, corrigés, étendus quand les utilisateurs et consommateurs expriment de nouveaux besoins. Le résultat en est que la plus grande part de l'activité de génie logiciel peut être classifié comme de la Maintenance Logicielle, « La totalité des activités requises pour fournir un support efficient d'un système logiciel ».Dans un écosystème où la puissance de calcul des ordinateurs, ou beaucoup d'autres métriques reliées comme la capacité des disques, ou le débit des réseaux, double tous les 18 mois (« loi de Moore »), les technologies évoluent rapidement. Dans cet écosystème la maintenance logiciel souffre de l'inconvénient de devoir traiter le passé (langages du passé, systèmes existants, vielles technologies). Elle est souvent mal perçue et traitée comme une punition. À cause de cela, les solutions et les outils pour la maintenance logicielle sont depuis toujours très en retard sur ceux pour le développement. Par exemple, l'antique méthode de correction de problème consistant à insérer des instructions pour retracer et comprendre le flot d'exécution d'un programme est toujours complètement actuelle.Toute mon activité de recherche s'est concentrée à aider les gens à faire de la maintenance logicielle dans de meilleures conditions ou plus efficacement. Une approche holistique du problème doit considérer le logiciel qui doit être maintenu, les gens qui le font et les organisations dans lesquelles et pour lesquelles cela est fait. Pour cela, j'ai étudié différents aspects du problème qui seront présentés en trois parties dans ce document : Le Logiciel : Le code source est la pièce centrale de l'activité de maintenance logicielle. Quelque soit la tâche (ex : amélioration ou correction d'erreur), elle revient typiquement à comprendre le code source actuel pour trouver quoi changer et/ou ajouter pour obtenir le comportement souhaité. J'ai étudié comment contrôler l'évolution du code source, comment prévenir son délitement et comment remédier à des mauvaises situations ; les Gens : L'un des principaux avantages des personnes qui traitent de maintenance logicielle est les connaissances qu'elles ont de l'informatique (techniques de programmation), du domaine d'application, du logiciel lui-même. Il est très significatif que de 40 % à 60 % du temps de maintenance logicielle soit passé à lire le code pour comprendre ce qu'il fait, comment il le fait et comment il peut-être changé ; les Organisations : Elles peuvent avoir un profond impact sur la façon dont des activités comme la maintenance logicielle sont exécutées par les individus. Le support offert à l'intérieur des organisations, ou les contraintes qu'elles imposent, l’environnement culturel, peuvent tous affecter la facilité ou difficulté de ces tâches et donc la qualité qui en résultera. J'ai étudié quelques processus liés à la maintenance logicielle utilisés dans les organisations.Dans ce document, les différents sujets de recherche que j'ai considéré sont présentés de façon logique qui ne respecte pas toujours l'ordre chronologique des évènements. J'ai souhaité aussi mettre en valeur, non uniquement les résultats scientifiques de mes recherches, au travers des publications qui les attestent, mais aussi les collaborations qui les ont rendus possibles, collaborations avec des étudiants ou des collègues chercheurs. Pour chaque résultat présenté ici, j'ai tenté de résumer le plus possible les discussions sur l'état de l'art antérieur et les résultats eux-mêmes. Ce d'abord parce que de plus amples détails peuvent facilement être trouvés dans les publications citées, mais aussi parce que une part de cette recherche est maintenant vielle et peux parfois être tombé dans le domaine du « sens commun »

Yavaa: supporting data workflows from discovery to visualization

Recent years have witness an increasing number of data silos being opened up both within organizations and to the general public: Scientists publish their raw data as supplements to articles or even standalone artifacts to enable others to verify and extend their work. Governments pass laws to open up formerly protected data treasures to improve accountability and transparency as well as to enable new business ideas based on this public good. Even companies share structured information about their products and services to advertise their use and thus increase revenue. Exploiting this wealth of information holds many challenges for users, though. Oftentimes data is provided as tables whose sheer endless rows of daunting numbers are barely accessible. InfoVis can mitigate this gap. However, offered visualization options are generally very limited and next to no support is given in applying any of them. The same holds true for data wrangling. Only very few options to adjust the data to the current needs and barely any protection are in place to prevent even the most obvious mistakes. When it comes to data from multiple providers, the situation gets even bleaker. Only recently tools emerged to search for datasets across institutional borders reasonably. Easy-to-use ways to combine these datasets are still missing, though. Finally, results generally lack proper documentation of their provenance. So even the most compelling visualizations can be called into question when their coming about remains unclear. The foundations for a vivid exchange and exploitation of open data are set, but the barrier of entry remains relatively high, especially for non-expert users. This thesis aims to lower that barrier by providing tools and assistance, reducing the amount of prior experience and skills required. It covers the whole workflow ranging from identifying proper datasets, over possible transformations, up until the export of the result in the form of suitable visualizations