DOCSLIB.ORG

Datalog on Infinite Structures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Datalog on Infinite Structures DISSERTATION zur Erlangung des akademischen Grades doctor rerum naturalium (Dr. rer. nat.) im Fach Informatik eingereicht an der Mathematisch-Naturwissenschaftlichen Fakultät II Humboldt-Universität zu Berlin von Herr Dipl.-Math. Goetz Schwandtner geboren am 10.09.1976 in Mainz Präsident der Humboldt-Universität zu Berlin: Prof. Dr. Christoph Markschies Dekan der Mathematisch-Naturwissenschaftlichen Fakultät II: Prof. Dr. Wolfgang Coy Gutachter: 1. Prof. Dr. Martin Grohe 2. Prof. Dr. Nicole Schweikardt 3. Prof. Dr. Thomas Schwentick Tag der mündlichen Prüfung: 24. Oktober 2008 Abstract Datalog is the relational variant of logic programming and has become a standard query language in database theory. The (program) complexity of datalog in its main context so far, on finite databases, is well known to be in EXPTIME. We research the complexity of datalog on infinite databases, motivated by possible applications of datalog to infinite structures (e.g. linear orders) in temporal and spatial reasoning on one hand and the upcoming interest in infinite structures in problems related to datalog, like constraint satisfaction problems: Unlike datalog on finite databases, on infinite structures the computations may take infinitely long, leading to the undecidability of datalog on some infinite struc- tures. But even in the decidable cases datalog on infinite structures may have ar- bitrarily high complexity, and because of this result, we research some structures with the lowest complexity of datalog on infinite structures: Datalog on linear orders (also dense or discrete, with and without constants, even colored) and tree orders has EXPTIME-complete complexity. To achieve the upper bound on these structures, we introduce a tool set specialized for datalog on orders: Order types, distance types and type disjoint programs. The type concept yields a finite representation of the infinite program results, which could also be of interest for practical applications. We create special type disjoint versions of the programs allowing to solve datalog without the recursion inherent in each datalog program. A transfer of our methods shows that constraint satisfaction problems on infinite structures occur with arbitrarily high time complexity, like datalog. Keywords: Datalog, Infinite Structures, Complexity, Decidability Zusammenfassung Datalog ist die relationale Variante der logischen Programmierung und ist eine Stan- dard-Abfragesprache in der Datenbankentheorie geworden. Die Programmkomplexi- tät von Datalog im bisherigen Hauptanwendungsgebiet, auf endlichen Strukturen, ist bekanntermassen in EXPTIME. Wir untersuchen die Komplexität von Datalog auf unendlichen Strukturen, motiviert durch mögliche Anwendungen von Datalog auf unendlichen Strukturen (z.B. linearen Ordnungen) im zeitlichen und räumlichen Schliessen, aber auch durch das aufkommende Interesse an unendlichen Strukturen bei verwandten theoretischen Problemen, wie Constraint Satisfaction Problems (CSP): Im Gegensatz zu endlichen Strukturen können Datalog-Berechnungen auf unend- lichen Strukturen unendlich lange dauern, was zur Unentscheidbarkeit von Datalog auf unendlichen Strukturen führen kann. Aber auch in den entscheidbaren Fällen kann die Komplexität von Datalog auf unendlichen Strukturen beliebig hoch sein. Im Hinblick auf dieses Ergebnis widmen wir uns dann unendlichen Strukturen mit der niedrigsten Komplexität von Datalog: Wir zeigen, dass Datalog auf linearen Ordnun- gen (auch dichte und diskrete, mit oder ohne Konstanten und sogar gefärbte) und Baumordnungen EXPTIME-vollständig ist. Für die Bestimmung der oberen Schranke werden Werkzeuge für Datalog auf Ordnungen eingeführt: Ordnungstypen, Abstandstypen und typdisjunkte Program- me. Die Typkonzepte liefern eine endliche Beschreibung der unendlichen Program- mergebnisse und könnten auch für praktische Anwendungen von Interesse sein. Wir erzeugen spezielle typdisjunkte Programme, die sich ohne Rekursion lösen lassen. Ein Transfer unserer Methoden auf CSPs zeigt, dass CSPs auf unendlichen Struk- turen mit beliebig hoher Zeitkomplexität vorkommen, wie Datalog. Schlagwörter: Datalog, Unendliche Strukturen, Komplexität, Entscheidbarkeit Acknowledgements I want to thank my thesis advisor Martin Grohe for guiding me through the world of datalog on infinite structures in many valuable discussions and with many helpful suggestions and comments on my ideas. I thank Nicole Schweikardt for several inter- esting discussions leading to new ideas and views on the research presented in this thesis. I am grateful to Mark Weyer for his careful proofreading of most of my ideas and pointing out mistakes in the proofs, and of course for his suggestions about possible solutions. Thanks go to Thomas Gottron and Kord Eickmeyer for proofreading parts of this thesis. Although he has not participated in the work at this thesis directly, I want to thank my former advisor Clemens Lautemann. With his interesting lectures and seminars and in numerous discussions he has aroused my curiosity about questions in computer science, especially in complexity theory and logics. Sad, that he passed away so soon! I am thankful to my colleagues at the computer science department at the Jo- hannes Gutenberg-University in Mainz, especially Elmar Schömer, to enable me to finish my research project after the sudden loss of my former advisor and also Thomas Schwentick for suggesting Martin as new advisor. Last but not least I thank my parents for their continuing support. v vi Contents 1 Introduction1 1.1 Published Results.............................5 1.2 Outline of This Thesis..........................5 2 Datalog, Infinite Structures9 2.1 Notations from Logics and Model Theory................9 2.1.1 Structures.............................9 2.1.2 Homomorphisms......................... 10 2.2 Datalog.................................. 10 2.2.1 Datalog Computation....................... 10 2.2.2 Program Parameters....................... 13 2.2.3 Datalog and Logics........................ 13 2.2.4 Datalog and Negation...................... 13 2.3 Datalog Problems............................. 14 2.4 Linear Orders and Successor Structures................. 15 2.5 Representation of Infinite Structures.................. 16 2.5.1 Representations and Datalog................... 16 2.5.2 Computational Model Theory.................. 19 2.6 Allen’s Interval Algebra......................... 21 3 Lower Bounds for Datalog 25 3.1 Universal Turing Machine Simulation.................. 25 3.2 EXPTIME-hard Lower Bound...................... 27 3.3 Summary of this Chapter......................... 29 4 Undecidability of Datalog on Infinite Structures 31 4.1 Successor Structures........................... 31 4.2 Successor-Like Structures......................... 32 4.2.1 Beyond Decidability....................... 35 4.2.2 Undecidability and Boundedness................ 36 4.3 Structures for Complexity Functions.................. 37 4.3.1 Lower Bounds........................... 38 4.3.2 Datalog Games.......................... 40 4.4 Summary of this Chapter......................... 46 vii 5 Types and Upper Bounds 49 5.1 Distance Types.............................. 50 5.2 Simple Cases............................... 56 5.2.1 Non-Strict Orders......................... 57 5.2.2 Monadic Datalog......................... 57 5.3 DATALOG-NONEMPTINESS on Orders................ 59 5.4 Boundedness and DATALOG-TUPLE on Orders............ 63 5.5 Datalog on Dense Orders......................... 70 5.6 Datalog on Orders with Constants.................... 73 5.7 Negation in Datalog Rules........................ 75 5.8 Representations and DATALOG-TUPLE................ 76 5.8.1 Monadic Datalog......................... 76 5.8.2 Linear Orders........................... 77 5.8.3 Dense Linear Orders....................... 77 5.8.4 Linear Orders With Constants.................. 77 5.8.5 Decidable Structures....................... 77 5.9 Summary of this Chapter......................... 78 6 Datalog on Colored Orders 81 6.1 Colored Orders.............................. 82 6.1.1 Colored Orders and Types.................... 83 6.1.2 Interval Types........................... 84 6.1.3 Modifying Datalog Programs.................. 95 6.2 Orders with one Monadic Relation and Constants........... 96 6.3 Colored Orders With Constants..................... 104 6.3.1 A Partition Lemma for Infinite Linear Orders......... 105 6.3.2 Monadic Memberships...................... 108 6.3.3 Structure Transformations.................... 108 6.3.4 Program Transformations.................... 113 6.4 Negation in Datalog Rules........................ 119 6.5 Colored Orders and DATALOG-TUPLE................ 120 6.6 Summary of this Chapter......................... 122 7 Datalog on Tree Orders 125 7.1 Preliminaries............................... 126 7.1.1 Tree Orders............................ 126 7.1.2 DATLOG-NONEMPTINESS and Homomorphisms...... 127 7.2 Upper Bound for Tree Orders...................... 128 7.3 Upper Bounds for Tree Orders with Constants............. 129 7.4 Tree Orders with Dense Parts...................... 135 7.5 Tree Order Variants............................ 137 7.6 DATALOG-TUPLE............................ 138 7.7 Tree Orders and Negation........................ 139 7.8 Summary of this Chapter......................... 139 viii 8 Constraint Satisfaction 141 8.1 CSPs.................................... 141 8.2 Transfer of Order Results to CSP.................... 144 8.3 EXPTIME-Undecidable Non-Dichotomy...............
Recommended publications
  • Dedalus: Datalog in Time and Space

    Dedalus: Datalog in Time and Space

    Dedalus: Datalog in Time and Space Peter Alvaro1, William R. Marczak1, Neil Conway1, Joseph M. Hellerstein1, David Maier2, and Russell Sears3 1 University of California, Berkeley {palvaro,wrm,nrc,hellerstein}@cs.berkeley.edu 2 Portland State University [email protected] 3 Yahoo! Research [email protected] Abstract. Recent research has explored using Datalog-based languages to ex- press a distributed system as a set of logical invariants. Two properties of dis- tributed systems proved difficult to model in Datalog. First, the state of any such system evolves with its execution. Second, deductions in these systems may be arbitrarily delayed, dropped, or reordered by the unreliable network links they must traverse. Previous efforts addressed the former by extending Datalog to in- clude updates, key constraints, persistence and events, and the latter by assuming ordered and reliable delivery while ignoring delay. These details have a semantics outside Datalog, which increases the complexity of the language and its interpre- tation, and forces programmers to think operationally. We argue that the missing component from these previous languages is a notion of time. In this paper we present Dedalus, a foundation language for programming and reasoning about distributed systems. Dedalus reduces to a subset of Datalog with negation, aggregate functions, successor and choice, and adds an explicit notion of logical time to the language. We show that Dedalus provides a declarative foundation for the two signature features of distributed systems: mutable state, and asynchronous processing and communication. Given these two features, we address two important properties of programs in a domain-specific manner: a no- tion of safety appropriate to non-terminating computations, and stratified mono- tonic reasoning with negation over time.
  • GRAPH DATABASE THEORY Comparing Graph and Relational Data Models

    GRAPH DATABASE THEORY Comparing Graph and Relational Data Models

    GRAPH DATABASE THEORY Comparing Graph and Relational Data Models Sridhar Ramachandran LambdaZen © 2015 Contents Introduction .................................................................................................................................................. 3 Relational Data Model .............................................................................................................................. 3 Graph databases ....................................................................................................................................... 3 Graph Schemas ............................................................................................................................................. 4 Selecting vertex labels .............................................................................................................................. 4 Examples of label selection ....................................................................................................................... 4 Drawing a graph schema ........................................................................................................................... 6 Summary ................................................................................................................................................... 7 Converting ER models to graph schemas...................................................................................................... 9 ER models and diagrams ..........................................................................................................................
  • A Deductive Database with Datalog and SQL Query Languages

    A Deductive Database with Datalog and SQL Query Languages

    A Deductive Database with Datalog and SQL Query Languages FernandoFernando SSááenzenz PPéérez,rez, RafaelRafael CaballeroCaballero andand YolandaYolanda GarcGarcííaa--RuizRuiz GrupoGrupo dede ProgramaciProgramacióónn DeclarativaDeclarativa (GPD)(GPD) UniversidadUniversidad ComplutenseComplutense dede MadridMadrid (Spain)(Spain) 12/5/2011 APLAS 2011 1 ~ ContentsContents 1.1. IntroductionIntroduction 2.2. QueryQuery LanguagesLanguages 3.3. IntegrityIntegrity ConstraintsConstraints 4.4. DuplicatesDuplicates 5.5. OuterOuter JoinsJoins 6.6. AggregatesAggregates 7.7. DebuggersDebuggers andand TracersTracers 8.8. SQLSQL TestTest CaseCase GeneratorGenerator 9.9. ConclusionsConclusions 12/5/2011 APLAS 2011 2 ~ 1.1. IntroductionIntroduction SomeSome concepts:concepts: DatabaseDatabase (DB)(DB) DatabaseDatabase ManagementManagement SystemSystem (DBMS)(DBMS) DataData modelmodel (Abstract) data structures Operations Constraints 12/5/2011 APLAS 2011 3 ~ IntroductionIntroduction DeDe--factofacto standardstandard technologiestechnologies inin databases:databases: “Relational” model SQL But,But, aa currentcurrent trendtrend towardstowards deductivedeductive databases:databases: Datalog 2.0 Conference The resurgence of Datalog inin academiaacademia andand industryindustry Ontologies Semantic Web Social networks Policy languages 12/5/2011 APLAS 2011 4 ~ Introduction.Introduction. SystemsSystems Classic academic deductive systems: LDL++ (UCLA) CORAL (Univ. of Wisconsin) NAIL! (Stanford University) Ongoing developments Recent commercial
  • DATALOG and Constraints

    DATALOG and Constraints

    7. DATALOG and Constraints Peter Z. Revesz 7.1 Introduction Recursion is an important feature to express many natural queries. The most studied recursive query language for databases is called DATALOG, an ab- breviation for "Database logic programs." In Section 2.8 we gave the basic definitions for DATALOG, and we also saw that the language is not closed for important constraint classes such as linear equalities. We have also seen some results on restricting the language, and the resulting expressive power, in Section 4.4.1. In this chapter, we study the evaluation of DATALOG with constraints in more detail , focusing on classes of constraints for which the language is closed. In Section 7.2, we present a general evaluation method for DATALOG with constraints. In Section 7.3, we consider termination of query evaluation and define safety and data complexity. In the subsequent sections, we discuss the evaluation of DATALOG queries with particular types of constraints, and their applications. 7.2 Evaluation of DATALOG with Constraints The original definitions of recursion in Section 2.8 discussed unrestricted relations. We now consider constraint relations, and first show how DATALOG queries with constraints can be evaluated. Assume that we have a rule of the form Ro(xl, · · · , Xk) :- R1 (xl,l, · · ·, Xl ,k 1 ), • • ·, Rn(Xn,l, .. ·, Xn ,kn), '¢ , as well as, for i = 1, ... , n , facts (in the database, or derived) of the form where 'if;; is a conjunction of constraints. A constraint rule application of the above rule with these facts as input produces the following derived fact: Ro(x1 , ..
  • Data Definition Language (Ddl)

    Data Definition Language (Ddl)

    DATA DEFINITION LANGUAGE (DDL) CREATE CREATE SCHEMA AUTHORISATION Authentication: process the DBMS uses to verify that only registered users access the database - If using an enterprise RDBMS, you must be authenticated by the RDBMS - To be authenticated, you must log on to the RDBMS using an ID and password created by the database administrator - Every user ID is associated with a database schema Schema: a logical group of database objects that are related to each other - A schema belongs to a single user or application - A single database can hold multiple schemas that belong to different users or applications - Enforce a level of security by allowing each user to only see the tables that belong to them Syntax: CREATE SCHEMA AUTHORIZATION {creator}; - Command must be issued by the user who owns the schema o Eg. If you log on as JONES, you can only use CREATE SCHEMA AUTHORIZATION JONES; CREATE TABLE Syntax: CREATE TABLE table_name ( column1 data type [constraint], column2 data type [constraint], PRIMARY KEY(column1, column2), FOREIGN KEY(column2) REFERENCES table_name2; ); CREATE TABLE AS You can create a new table based on selected columns and rows of an existing table. The new table will copy the attribute names, data characteristics and rows of the original table. Example of creating a new table from components of another table: CREATE TABLE project AS SELECT emp_proj_code AS proj_code emp_proj_name AS proj_name emp_proj_desc AS proj_description emp_proj_date AS proj_start_date emp_proj_man AS proj_manager FROM employee; 3 CONSTRAINTS There are 2 types of constraints: - Column constraint – created with the column definition o Applies to a single column o Syntactically clearer and more meaningful o Can be expressed as a table constraint - Table constraint – created when you use the CONTRAINT keyword o Can apply to multiple columns in a table o Can be given a meaningful name and therefore modified by referencing its name o Cannot be expressed as a column constraint NOT NULL This constraint can only be a column constraint and cannot be named.
  • Constraint-Based Synthesis of Datalog Programs

    Constraint-Based Synthesis of Datalog Programs

    Constraint-Based Synthesis of Datalog Programs B Aws Albarghouthi1( ), Paraschos Koutris1, Mayur Naik2, and Calvin Smith1 1 University of Wisconsin–Madison, Madison, USA [email protected] 2 Unviersity of Pennsylvania, Philadelphia, USA Abstract. We study the problem of synthesizing recursive Datalog pro- grams from examples. We propose a constraint-based synthesis approach that uses an smt solver to efficiently navigate the space of Datalog pro- grams and their corresponding derivation trees. We demonstrate our technique’s ability to synthesize a range of graph-manipulating recursive programs from a small number of examples. In addition, we demonstrate our technique’s potential for use in automatic construction of program analyses from example programs and desired analysis output. 1 Introduction The program synthesis problem—as studied in verification and AI—involves con- structing an executable program that satisfies a specification. Recently, there has been a surge of interest in programming by example (pbe), where the specification is a set of input–output examples that the program should satisfy [2,7,11,14,22]. The primary motivations behind pbe have been to (i) allow end users with no programming knowledge to automatically construct desired computations by supplying examples, and (ii) enable automatic construction and repair of pro- grams from tests, e.g., in test-driven development [23]. In this paper, we present a constraint-based approach to synthesizing Data- log programs from examples. A Datalog program is comprised of a set of Horn clauses encoding monotone, recursive constraints between relations. Our pri- mary motivation in targeting Datalog is to expand the range of synthesizable programs to the new domains addressed by Datalog.
  • Datalog Logic As a Query Language a Logical Rule Anatomy of a Rule Anatomy of a Rule Sub-Goals Are Atoms

    Datalog Logic As a Query Language a Logical Rule Anatomy of a Rule Anatomy of a Rule Sub-Goals Are Atoms

    Logic As a Query Language If-then logical rules have been used in Datalog many systems. Most important today: EII (Enterprise Information Integration). Logical Rules Nonrecursive rules are equivalent to the core relational algebra. Recursion Recursive rules extend relational SQL-99 Recursion algebra --- have been used to add recursion to SQL-99. 1 2 A Logical Rule Anatomy of a Rule Our first example of a rule uses the Happy(d) <- Frequents(d,rest) AND relations: Likes(d,soda) AND Sells(rest,soda,p) Frequents(customer,rest), Likes(customer,soda), and Sells(rest,soda,price). The rule is a query asking for “happy” customers --- those that frequent a rest that serves a soda that they like. 3 4 Anatomy of a Rule sub-goals Are Atoms Happy(d) <- Frequents(d,rest) AND An atom is a predicate, or relation Likes(d,soda) AND Sells(rest,soda,p) name with variables or constants as arguments. Head = “consequent,” Body = “antecedent” = The head is an atom; the body is the a single sub-goal AND of sub-goals. AND of one or more atoms. Read this Convention: Predicates begin with a symbol “if” capital, variables begin with lower-case. 5 6 1 Example: Atom Example: Atom Sells(rest, soda, p) Sells(rest, soda, p) The predicate Arguments are = name of a variables relation 7 8 Interpreting Rules Interpreting Rules A variable appearing in the head is Rule meaning: called distinguished ; The head is true of the distinguished otherwise it is nondistinguished. variables if there exist values of the nondistinguished variables that make all sub-goals of the body true.
  • A Dictionary of DBMS Terms

    A Dictionary of DBMS Terms

    A Dictionary of DBMS Terms Access Plan Access plans are generated by the optimization component to implement queries submitted by users. ACID Properties ACID properties are transaction properties supported by DBMSs. ACID is an acronym for atomic, consistent, isolated, and durable. Address A location in memory where data are stored and can be retrieved. Aggregation Aggregation is the process of compiling information on an object, thereby abstracting a higher-level object. Aggregate Function A function that produces a single result based on the contents of an entire set of table rows. Alias Alias refers to the process of renaming a record. It is alternative name used for an attribute. 700 A Dictionary of DBMS Terms Anomaly The inconsistency that may result when a user attempts to update a table that contains redundant data. ANSI American National Standards Institute, one of the groups responsible for SQL standards. Application Program Interface (API) A set of functions in a particular programming language is used by a client that interfaces to a software system. ARIES ARIES is a recovery algorithm used by the recovery manager which is invoked after a crash. Armstrong’s Axioms Set of inference rules based on set of axioms that permit the algebraic mani- pulation of dependencies. Armstrong’s axioms enable the discovery of minimal cover of a set of functional dependencies. Associative Entity Type A weak entity type that depends on two or more entity types for its primary key. Attribute The differing data items within a relation. An attribute is a named column of a relation. Authorization The operation that verifies the permissions and access rights granted to a user.
  • Logical Query Languages

    Logical Query Languages

    Logical Query Languages Motivatio n: 1. Logical rules extend more naturally to recursive queries than do es relational algebra. ✦ Used in SQL recursion. 2. Logical rules form the basis for many information-integration systems and applications. 1 Datalog Example , beer Likesdrinker Sellsbar , beer , price Frequentsdrinker , bar Happyd <- Frequentsd,bar AND Likesd,beer AND Sellsbar,beer,p Ab oveisarule. Left side = head. Right side = body = AND of subgoals. Head and subgoals are atoms. ✦ Atom = predicate and arguments. ✦ Predicate = relation name or arithmetic predicate, e.g. <. ✦ Arguments are variables or constants. Subgoals not head may optionally b e negated by NOT. 2 Meaning of Rules Head is true of its arguments if there exist values for local variables those in b o dy, not in head that make all of the subgoals true. If no negation or arithmetic comparisons, just natural join the subgoals and pro ject onto the head variables. Example Ab ove rule equivalenttoHappyd = Frequents ./ Likes ./ Sells dr ink er 3 Evaluation of Rules Two, dual, approaches: 1. Variable-based : Consider all p ossible assignments of values to variables. If all subgoals are true, add the head to the result relation. 2. Tuple-based : Consider all assignments of tuples to subgoals that make each subgoal true. If the variables are assigned consistent values, add the head to the result. Example: Variable-Based Assignment Sx,y <- Rx,z AND Rz,y AND NOT Rx,y R = B A 1 2 2 3 4 Only assignments that make rst subgoal true: 1. x ! 1, z ! 2. 2. x ! 2, z ! 3. In case 1, y ! 3 makes second subgoal true.
  • Shadow Theory: Data Model Design for Data Integration

    Shadow Theory: Data Model Design for Data Integration

    Shadow Theory: Data Model Design for Data Integration Jason T. Liu* (Draft. Date:9/12/2012) ABSTRACT In information ecosystems, semantic heterogeneity is known as General Terms Algorithms, Design, Human Factors, Theory. the root issue for the difficulties of data integration, and the Relational Model is not designed for addressing such challenges, i.e. to re-use data that is modeled from other sources in the local Keywords data model design. Although researchers have proposed many Data integration, information ecosystems, shadows, meanings, different approaches, and software vendors have designed tools to mental entity, semantic heterogeneity, tags, help the data integration task, it remains an art relying on human labors. Due to lacks of a comprehensive theory to guide the overall modeling process, the quality of the integrated data heavily depends on the data integrators’ experiences. 1. Introduction Based on observations of practical issues for enterprise customer Data integration is essential for most enterprise systems that rely data integration, we believe that the needed solution is a new data on data from multiple sources. Lenzerini defined data integration model. This new data model needs to manage the difficulties of as to combine data residing at different sources in order to provide semantic heterogeneity: different data collected from different users with a unified view of these data [1]. Specifically, the goal perspectives about the same subject matter can naturally be of Enterprise Information Integration (EII) is to provide a uniform inconsistencies or even in conflicts. In other words, existing data access to multiple data sources without having to load the data models are designed to support single version of the truth, and into a central place [2].
  • Mapping OCL As a Query and Constraint Language Traduciendo OCL Como Lenguaje De Consultas Y Restricciones

    Mapping OCL As a Query and Constraint Language Traduciendo OCL Como Lenguaje De Consultas Y Restricciones

    UNIVERSIDAD COMPLUTENSE DE MADRID FACULTAD DE INFORMÁTICA Departamento de Sistemas Informáticos y Computación TESIS DOCTORAL Mapping OCL as a Query and Constraint Language Traduciendo OCL como lenguaje de consultas y restricciones MEMORIA PARA OPTAR AL GRADO DE DOCTOR PRESENTADA POR Carolina Inés Dania Flores Directores Manuel García Clavel Marina Egea González Madrid, 2018 © Carolina Inés Dania Flores, 2017 Tesis Doctoral Mapping OCL as a Query and Constraint Language Traduciendo OCL como Lenguaje de Consultas y Restricciones Carolina Inés Dania Flores Supervisors: Manuel García Clavel Marina Egea González Facultad de Informática Universidad Complutense de Madrid © Joaquín S. Lavado, QUINO. Toda Mafalda, Penguin Random House, España. Mapping OCL as a Query and Constraint Language Traduciendo OCL como Lenguaje de Consultas y Restricciones PhD Thesis Carolina In´es Dania Flores Advisors Manuel Garc´ıa Clavel Marina Egea Gonz´alez Departamento de Sistemas Inform´aticos y Computaci´on Facultad de Inform´atica Universidad Complutense de Madrid 2017 Amifamiliadeall´a. Mi mam´aEstela, mi pap´aH´ector y mis hermanos Flor, Marcos y Leila. A mi familia de ac´a. Mi esposo Israel, mi perro Yiyo y mis suegros Marinieves y Jacinto. A mi gran amigo de all´a, mi querido Julio. A mi gran amigo de ac´a, mi querido Juli. Acknowledgments Undertaking this PhD has been a truly life-changing experience for me, and it would not have been possible without the support and guidance that I received from many people. I would like to express my sincere gratitude to my supervisors, Manuel Garc´ıa Clavel and Marina Egea, for their support during these years.
  • A Theory of Regular Queries

    A Theory of Regular Queries

    A Theory of Regular Queries Moshe Y. Vardi Rice University [email protected] ABSTRACT [22], he proposed using first-order logic as a declarative database A major theme in relational database theory is navigat- query language [23]. This led to the development of both ing the tradeoff between expressiveness and tractability for SEQUEL [16] and QUEL [54], as practical relational query query languages, where the query-containment problem is languages realizing Codd's idea, ultimately giving in 1986 considered a benchmark of tractability. The query class rise to the SQL standard [27], which has continued to evolve UCQ, consisting off unions of conjunctive queries, is a frag- over the past 30 years. ment of first-order logic that has a decidable query contain- Starting in the late 1970s, Codd's definition of first-order ment problem, but its expressiveness is limited. Extend- logic as \expressively complete" came under serious criti- ing UCQ with recursion yields Datalog, an expressive query cism [4], and various proposals emerged on how to extend language that has been studied extensively and has recently its expressive power [4, 6, 17], whose essence was to extend become popular in application areas such as declarative net- first-order logic with recursion, which was added to SQL in working. Unfortunately, Datalog has an undecidable query 1999 by way of common table expressions [29]. On the re- containment problem. Identifying a fragment of Datalog search side, the most popular relational language embodying that is expressive enough for applications but has a decid- recursion is Datalog [15], describe in more details below.