DOCSLIB.ORG

A Deductive Database with Datalog and SQL Query Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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 deductive systems: DLV (Italy, University of Calabria) LogicBlox (USA) Intellidimension (USA) Semmle (UK) Recent academic deductive systems: 4QL (Warsaw University) bddbddb (Stanford University) ConceptBase (Passau, Aachen, Tilburg Universities, since 1987) XSB (Stony Brook University, Universidade Nova de Lisboa, XSB, Inc., Katholieke Universiteit LeuvLeuven,en, and Uppsala Universitet) DES (Complutense University) 12/5/2011 APLAS 2011 5 ~ DatalogDatalog EducationalEducational SystemSystem (DES)(DES) YetYet anotheranother system,system, Why?Why? WeWe neededneeded anan interactiveinteractive systemsystem targetedtargeted atat teachingteaching DatalogDatalog inin classroomsclassrooms So,So, whatwhat aa wholewhole setset ofof featuresfeatures wewe werewere askingasking forfor suchsuch aa system?system? A system oriented at teaching User-friendly: Installation Usability Multiplatform (Windows, Linux, Mac, …) Interactive Query languages … 12/5/2011 APLAS 2011 6 ~ DESDES ConcreteConcrete FeaturesFeatures (1/4)(1/4) Free,Free, OpenOpen--source,source, Multiplatform,Multiplatform, PortablePortable QueryQuery languages:languages: (Extended)(Extended) DatalogDatalog (Recursive)(Recursive) SQLSQL followingfollowing ANSI/ISOANSI/ISO standardstandard StratifiedStratified NegationNegation IntegrityIntegrity constraintsconstraints DuplicatesDuplicates NullNull valuevalue supportsupport àà lala SQLSQL OuterOuter joinsjoins forfor bothboth SQLSQL andand DatalogDatalog AggregatesAggregates 12/5/2011 APLAS 2011 7 ~ DESDES ConcreteConcrete FeaturesFeatures (2/4)(2/4) DeclarativeDeclarative debuggersdebuggers andand tracerstracers TestTest casecase generatorgenerator forfor SQLSQL viewsviews FullFull--fledgedfledged arithmeticarithmetic DatabaseDatabase updatesupdates TemporaryTemporary DatalogDatalog viewsviews TypeType systemsystem BatchBatch processingprocessing TextualTextual APIAPI 12/5/2011 APLAS 2011 8 ~ DESDES ConcreteConcrete FeaturesFeatures (3/4)(3/4) ProgramProgram analysis:analysis: Safe rules (classical safety for range restriction) Negation Head variables Safe metapredicates Aggregates Duplicate elimination SourceSource--toto--sourcesource programprogram transformations:transformations: Safety (command /safe on) Aggregates (solving) Performance (/simplification on) ... 12/5/2011 APLAS 2011 9 ~ DESDES ConcreteConcrete FeaturesFeatures (4/4)(4/4) But,But, quitequite relevantrelevant featuresfeatures are:are: InteractivenessInteractiveness Database updates A wide set of commands (>70) EasyEasy toto installinstall andand useuse des.sourceforge.net RobustRobust (up(up toto bugs)bugs) 12/5/2011 APLAS 2011 10 ~ DESDES allowsallows TeachTeach (Declarative)(Declarative) QueryQuery Languages:Languages: FromFrom SQLSQL toto DatalogDatalog ButBut alsoalso forfor rapidrapid prototyping:prototyping: NovelNovel features:features: SQL hypothetical queries Outer joins in Datalog Datalog and SQL declarative (algorithmic) debuggers and tracers Test case generation for SQL views ...... andand ExperimentExperiment withwith DatalogDatalog forfor researchresearch Theses,Theses, Papers,Papers, …… SeeSee DESDES FactsFacts atat itsits webweb pagepage 12/5/2011 APLAS 2011 11 ~ 2.2. QueryQuery Languages.Languages. DatalogDatalog AA databasedatabase queryquery languagelanguage stemmingstemming fromfrom PrologProlog Prolog Datalog Predicate Relation Goal Query Goals are solved one answer at a time (backtracking) Queries are solved by computing its meaning once DeductiveDeductive database:database: Extensional database: Facts Intensional database: Rules. 12/5/2011 APLAS 2011 12 ~ DatalogDatalog DatalogDatalog differsdiffers fromfrom Prolog:Prolog: Datalog does not allow function symbols in arguments Facts are ground (safety) Datalog is truly declarative: Clause order is irrelevant Order of literals in a body is irrelevant No extra-logical constructors as the feared cut 12/5/2011 APLAS 2011 13 ~ DatalogDatalog SyntaxSyntax Program: Set of rules. Rule: head :- body. ground_head. Head: Positive atom. Body: Conjunctions (,) and disjunctions (;) of literals Literal: Atom, Built-in (>, <, …). Query: Literal with variables or constants in arguments Body (Conjunctive queries, …) 12/5/2011 APLAS 2011 14 ~ QueryQuery Languages.Languages. SQLSQL Follows ISO Standard DQL: SELECT Expressions FROM Relations WHERE Condition WITH RECURSIVE LocalViewDefs Statement ASSUME LocalViewDefs IN Statement (ongoing work) DML: INSERT … UPDATE … DELETE … DDL: CREATE [OR REPLACE] TABLE … CREATE [OR REPLACE] VIEW … DROP … 12/5/2011 APLAS 2011 15 ~ DatalogDatalog andand SQLSQL inin DESDES DES Datalog SQL Deductive engine (DE): Deductive Engine Tabling implementation Cache Datalog programs are solved by DE ODBC In-memory Compilation of SQL views and Prolog (MySQL, Access, SQL Server, queries to Datalog programs DB Oracle, DB2,...) SQL queries are also solved by DE Interoperability is allowed: SQL and Datalog do share the deductive database! Datalog queries ↔ SQL queries Datalog typed relations ↔ SQL tables and views 12/5/2011 APLAS 2011 16 ~ DatalogDatalog tom grace ExampleExample jack amy tony carolI Facts: fred carolII father(tom,amy). father(jack,fred). carolIII father(tony,carolII). father(fred,carolIII). mother(graceI,amy). mother(amy,fred). mother(carolI,carolII). Query: mother(carolII,carolIII). parent(X,Y) Rules: Minimal model for parent: { parent(X,Y) :- father(X,Y). (tom,amy), (grace,amy), (jack,fred), parent(X,Y) :- mother(X,Y). (amy,fred), … } 12/5/2011 APLAS 2011 17 ~ tom grace RecursionRecursion jack amy tony carolI father(tom,amy). fred carolII father(jack,fred). father(tony,carolII). father(fred,carolIII). carolIII mother(graceI,amy). mother(amy,fred). DES implements a fixpoint semantics for recursive mother(carolI,carolII). Datalog, finding the least fixpoint as answer mother(carolII,carolIII). parent(X,Y) :- father(X,Y). ancestor(tom,X) parent(X,Y) :- mother(X,Y). { ancestor(X,Y) :- ancestor(tom,amy), parent(X,Y). ancestor(tom,carolIII), ancestor(X,Y) :- ancestor(tom,fred) parent(X,Z), } ancestor(Z,Y). 12/5/2011 APLAS 2011 18 ~ SQLSQL RecursionRecursion asas ofof CurrentCurrent DBMS'sDBMS's CREATE VIEW parent(parent,child) AS SELECT * FROM father UNION SELECT * FROM mother; CREATE OR REPLACE VIEW ancestor(ancestor,descendant) AS WITH RECURSIVE rec_ancestor(ancestor,descendant) AS SELECT * FROM parent UNION SELECT parent,descendant FROM parent,rec_ancestor WHERE parent.child=rec_ancestor.ancestor SELECT * FROM rec_ancestor; DES-SQL> SELECT * FROM ancestor WHERE ancestor='tom'; 12/5/2011 APLAS 2011 19 ~ SQLSQL SimplifiedSimplified SyntaxSyntax inin DESDES Simply:Simply: CREATE OR REPLACE VIEW ancestor(ancestor, descendant) AS SELECT * FROM parent UNION SELECT parent, descendant FROM parent, ancestor WHERE parent.child=ancestor.ancestor; InsteadInstead ofof resortingresorting toto WITH:WITH: CREATE OR REPLACE VIEW ancestor(ancestor,descendant) AS WITH RECURSIVE rec_ancestor(ancestor,descendant) AS SELECT * FROM parent UNION SELECT parent, descendant FROM parent, rec_ancestor WHERE parent.child=rec_ancestor.ancestor SELECT * FROM rec_ancestor; 12/5/2011 APLAS 2011 20 ~ SQLSQL HypotheticalHypothetical QueriesQueries CREATE TABLE flight(origin string, destination string, time real) INSERT INTO flight VALUES('lon','ny',9.0); INSERT INTO flight VALUES('mad','par',1.5); INSERT INTO flight VALUES('par','ny',10.0); CREATE VIEW travel(origin,destination,time) AS WITH connected(origin,destination,time) AS SELECT * FROM flight UNION SELECT flight.origin, connected.destination, flight.time+connected.time FROM flight, connected WHERE flight.destination = connected.origin SELECT * FROM connected; 12/5/2011 APLAS 2011 21 ~ SQLSQL HypotheticalHypothetical QueriesQueries DES-Datalog> SELECT * FROM travel { answer(lon,ny,9.0), answer(mad,ny,11.5), answer(mad,par,1.5), answer(par,ny,10.0) } Info: 4 tuples computed. DES-Datalog> ASSUME SELECT 'mad','lon',2.0 IN flight(origin,destination,time)
Recommended publications
  • A Fuzzy Datalog Deductive Database System 1

    A Fuzzy Datalog Deductive Database System 1

    A FUZZY DATALOG DEDUCTIVE DATABASE SYSTEM 1 A Fuzzy Datalog Deductive Database System Pascual Julian-Iranzo,´ Fernando Saenz-P´ erez´ Abstract—This paper describes a proposal for a deduc- particular, non-logic constructors are disallowed, as the cut), tive database system with fuzzy Datalog as its query lan- but it is not Turing-complete as it is meant as a database query guage. Concepts supporting the fuzzy logic programming sys- language. tem Bousi∼Prolog are tailored to the needs of the deductive database system DES. We develop a version of fuzzy Datalog Fuzzy Datalog [9] is an extension of Datalog-like languages where programs and queries are compiled to the DES core using lower bounds of uncertainty degrees in facts and rules. Datalog language. Weak unification and weak SLD resolution are Akin proposals as [10], [11] explicitly include the computation adapted for this setting, and extended to allow rules with truth de- of the rule degree, as well as an additional argument to gree annotations. We provide a public implementation in Prolog represent this degree. However, and similar to Bousi∼Prolog, which is open-source, multiplatform, portable, and in-memory, featuring a graphical user interface. A distinctive feature of this we are interested in removing this burden from the user system is that, unlike others, we have formally demonstrated with an automatic rule transformation that elides both the that our implementation techniques fit the proposed operational degree argument and the explicit call to fuzzy connective semantics. We also study the efficiency of these implementation computations in user rules. In addition, we provide support for techniques through a series of detailed experiments.
  • 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.
  • Comparative Study of Database Modeling Approaches

    Comparative Study of Database Modeling Approaches

    COMPARATIVE STUDY OF DATABASE MODELING APPROACHES Department of Computer Science Algoma University APRIL 2014 Advisor Dr. Simon Xu By Mohammed Aljarallah ABSTRACT An overview and comparative study of different database modeling approaches have been conducted in the thesis. The foundation of every structure is important and if the foundation is weak the whole system can collapse and database is the foundation of every software system. The complexity and simplicity of this core area of software development is also a very important issue as different modeling techniques are used according to the requirements of software and evaluation of these techniques is necessary. The approach of the thesis is a literature survey and background of data modeling techniques. All the requirements of data modeling and database systems are encapsulated here along with the structure of database. The foundation of the thesis is developed by discussing some of the cases studies regarding the database models from the practical field to develop an understanding of database systems, models and techniques from the practical perspective. The study of database system and most of the models are investigated in the thesis to establish a scenario in which these modeling approaches could be compared in a more innovative and better way. Relational database modeling approach is one of the important techniques used to develop the database system and the technique that could be used as replacement of relational model as single or in hybrid way is also an interesting aspect of survey. The comparisons of traditional and modern database modeling methodologies are also discussed here to highlight the features of current database management systems.
  • 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 , ..
  • Some Experiments on the Usage of a Deductive Database for RDFS Querying and Reasoning

    Some Experiments on the Usage of a Deductive Database for RDFS Querying and Reasoning

    Some experiments on the usage of a deductive database for RDFS querying and reasoning Giovambattista Ianni1;2, Alessandra Martello1, Claudio Panetta1, and Giorgio Terracina1 1 Dipartimento di Matematica, Universit`adella Calabria, I-87036 Rende (CS), Italy, 2 Institut fÄurInformationssysteme 184/3, Technische UniversitÄatWien Favoritenstra¼e 9-11, A-1040 Vienna, Austria fianni,a.martello,panetta,[email protected] Abstract. Ontologies are pervading many areas of knowledge represen- tation and management. To date, most research e®orts have been spent on the development of su±ciently expressive languages for the represen- tation and querying of ontologies; however, querying e±ciency has re- ceived attention only recently, especially for ontologies referring to large amounts of data. In fact, it is still uncertain how reasoning tasks will scale when applied on massive amounts of data. This work is a ¯rst step toward this setting: based on a previous result showing that the SPARQL query language can be mapped to a Datalog, we show how e±cient querying of big ontologies can be accomplished with a database oriented exten- sion of the well known system DLV, recently developed. We report our initial results and we discuss about bene¯ts of possible alternative data structures for representing RDF graphs in our architecture. 1 Introduction The Semantic Web [4, 11] is an extension of the current Web by standards and technologies that help machines to understand the information on the Web so that they can support richer discovery, data integration, navigation, and au- tomation of tasks. Roughly, the main ideas behind the Semantic Web aim to (i) add a machine-readable meaning to Web pages, (ii) use ontologies for a precise de¯nition of shared terms in Web resources, (iii) make use of KR technology for automated reasoning on Web resources, and (iv) apply cooperative agent technology for processing the information of the Web.
  • 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.
  • DES: a Deductive Database System Des.Sourceforge.Net

    DES: a Deductive Database System Des.Sourceforge.Net

    DES: A Deductive Database System des.sourceforge.net FernandoFernando SSááenzenz PPéérezrez GrupoGrupo dede ProgramaciProgramacióónn DeclarativaDeclarativa (GPD)(GPD) DeptDept.. IngenierIngenierííaa deldel SoftwareSoftware ee InteligenciaInteligencia ArtificialArtificial UniversidadUniversidad ComplutenseComplutense dede MadridMadrid FacultadFacultad dede InformInformááticatica PROLE 2010 10/9/2010 1 / 30 ContentsContents 1.1. IntroductionIntroduction 2.2. FeaturesFeatures 3.3. QueryQuery LanguagesLanguages 4.4. OuterOuter JoinsJoins 5.5. AggregatesAggregates 6.6. DESDES asas aa TestTest--BedBed forfor ResearchResearch 7.7. ImpactImpact FactorFactor 8.8. ConclusionsConclusions PROLE 2010 10/9/2010 2 / 30 1.1. IntroductionIntroduction Databases:Databases: FromFrom relationalrelational toto deductivedeductive (Declarative)(Declarative) QueryQuery Languages:Languages: FromFrom SQLSQL toto DatalogDatalog PROLE 2010 10/9/2010 3 / 30 1.1. Introduction:Introduction: DatalogDatalog AA databasedatabase queryquery languagelanguage stemmingstemming fromfrom PrologProlog PrologProlog DatalogDatalog PredicatePredicate RelationRelation GoalGoal QueryQuery MeaningMeaning ofof aa predicatepredicate ((Multi)setMulti)set ofof derivablederivable factsfacts Intensionally (Rules or Clauses) Extensionally (Facts) PROLE 2010 10/9/2010 4 / 30 1.1. Introduction:Introduction: DatalogDatalog WhatWhat aa typicaltypical databasedatabase useruser wouldwould expectexpect fromfrom aa queryquery language?language? FiniteFinite data,data, finitefinite computationscomputations
  • 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.
  • Tilburg University a Deductive Database Management System in Prolog Gelsing, P.P

    Tilburg University a Deductive Database Management System in Prolog Gelsing, P.P

    Tilburg University A deductive database management system in Prolog Gelsing, P.P. Publication date: 1989 Document Version Publisher's PDF, also known as Version of record Link to publication in Tilburg University Research Portal Citation for published version (APA): Gelsing, P. P. (1989). A deductive database management system in Prolog. (ITK Research Memo). Institute for Language Technology and Artifical IntelIigence, Tilburg University. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 27. sep. 2021 i CBM ~~ R ~~ , r ~~~: `j 8419 ~`~~~ ~~~` 1989 J~~~ ~ iiiiiiiuiiiiiuiiuiiuiiiuiiiiiiiui ~ C I N 0 0 2 8 3~ 4 INSTITUTE FOR LANGUAGE TECHNOLOGY AND ARTIFICIAL INTELLIGENCE INSTITUUT VOOR TAAL- EN KENNISTECHNOLOGIE r~~. , `-,~ d i~;~!í;'~:.1l.B. ~ ~,,~~'.;, ~:~; ! 7T!-!-~K J~ , TtL~i~1:-y!(à I.T.K. Research Memo no. 4 November 1989 A Deductive Database Management System in Prolog Paul P. Gelsing Institute for Language Technology and Artificizl Intelligence, Tilburg University, The Netherlands Table of Contents Introduction .
  • A Basis for Deductive Database Systems Ii

    A Basis for Deductive Database Systems Ii

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector J. LOGIC PROGRAMMING 1986:1:55-67 55 A BASIS FOR DEDUCTIVE DATABASE SYSTEMS II J. W. LLOYD AND R. W. TOPOR* D This paper is the third in a series providing a theoretical basis for deductive database systems. A deductive database consists of closed typed first order logic formulas of the form A + W, where A is an atom and W is a typed first order formula. A typed first order formula can be used as a query, and a closed typed first order formula can be used as an integrity constraint. Functions are allowed to appear in formulas. Such a deductive database system can be implemented using a PROLOG system. The main results of this paper are concerned with the nonfloundering and completeness of query evaluation. We also introduce an alternative query evaluation process and show that corresponding versions of the earlier results can be obtained. Finally, we summarize the results of the three papers and discuss the attractive properties of the deductive database system approach based on first order logic. a 1. INTRODUCTION The use of deductive database systems based on first order logic has recently received considerable interest because of their many attractive properties [3-6,131. In particular, first order logic has a well-developed theory and can be used as a uniform language for data, programs, queries, views, and integrity constraints. One promising approach to implementing deductive database systems is to use a PROLOG system as the query evaluator [2,7,9-11,15,16].
  • 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.
  • Rules in Database Systems J

    Rules in Database Systems J

    WDS'11 Proceedings of Contributed Papers, Part I, 131–136, 2011. ISBN 978-80-7378-184-2 © MATFYZPRESS Rules in Database Systems J. Koz´ak Charles University, Faculty of Mathematics and Physics, Prague, Czech Republic. Abstract. This paper deals with the principles of rule-based systems in databases and gives an overview of existing approaches. First, we introduce the concept of rules. The application of rule-based systems to databases is categorized. Deductive database systems are introduced as the first extension of classical database management systems. We briefly describe the concept of deductive databases and their language. The main part is dedicated to active database systems. Language and implementation of rules in active databases are discussed as well as rule processing and key issues connected with it. Also architecture of the active database systems is depicted. At the end, benchmark comparing different rule-based database technologies is presented. Introduction The very first thing coming into our minds might be a natural question: “What are the rules?” Generally, we can say that almost any commands, decision making or deductive rea- soning can be understood as a set of rules. This brief description implies that we meet rules in real life all the time although usually we do not even realize it. The previous interpretation becomes obvious when we start to think about implementation of intelligence into a machine i.e., making machines think like people. If we want to do that, then we have to tell the machine what to do in various situations which means to teach it in the way of stating the rules.