An Extended Relational Algebra for Declarative Programming *

Transcription

1 An Extended Relational Algebra for Declarative Programming * Jesús M. Almendros-Jiménez Dpto. de Lenguajes y Computación. Universidad de Almería. jalmen@ual.es Resumen Relational algebra is a well-known formalism for expressing queries against a relational database. In this paper we will present a relational algebra for declarative languages. It is based in the use of the operators of projection, selection, renaming, cross product, union and join. This relational algebra can be used for de- ning predicates and functions for a declarative language, and in general for dening clauses and rewriting rules. Finally, we will present a SQL-based syntax based on this relational algebra. 1. Introduction Relational algebra [5] is a well-known formalism for expressing queries against a relational database. It is based on the use of the algebra operators selection, projection, cross product, join, renaming, union and dierence. Relational algebra has also been studied in the socalled extensions of the relational model. For instance, relational algebra for object-oriented databases [10], constraint databases [7], web databases [6], deductive databases [1, 2], spatial databases [4] and temporal databases [9]. On the other hand, declarative (functional, logic) languages share with database languages many features: Database languages are usually declarative: symbolic handling of data, high-level compilation, and the use of program transformation and analysis techniques in or- * This work has been partially supported by the EU (FEDER) and the Spanish MEC under grant TIN C03-02 der to improve debugging and code optimization. However, they have not been suciently compared, although there are some approaches which attempt to integrate both kinds of languages like deductive and constraint databases [1, 7]. Here, we would like to compare both kinds of languages in the following sense. Declarative languages are equation and rule based languages, and usually these equations and rules are used for evaluating a term or goal, and the evaluation mechanism is based on resolution and rewriting [8, 3]. Database languages dene tables, and queries against the tables by means of (extensions of) SQL, which is based on the relational algebra. We would like to dene a relational algebra which is able to simulate the denitions of a declarative language (i.e. equations and rules) and which can be used for evaluating goals and terms, simulating resolution and rewriting. In other words, we would like to see a declarative language as a data denition language in which goal resolution and term reduction is a particular case of database query solving. In particular, we will like to dene an extension of SQL for declarative languages. The benets of this approach are the following: Firstly, to integrate database and declarative languages. Secondly, to have a new formalism for de- ning the denotational and operational semantics for declarative languages. An interesting consequence of our work is that declarative languages use clauses and rewriting rules for dening views (in the sense of databases) from a database whose 1

2 tuples consists of ground terms. Therefore, our work provides a semantic characterization of declarative languages in terms of tuples of ground terms and basic relational operators. Thirdly, the extended relational algebra can be the basis of an abstract machine which can be used for implementing declarative languages. Moreover, the handling of a database in a declarative language can be implemented using a database manager. Finally, this formalism can be used for studying code optimizations based on properties of the algebra operators and, in general, it can be used for analyzing, transforming and specializing declarative programs. Some techniques studied for optimizing and debugging declarative languages can be carried out to database languages by using the proposed translation. In this paper we will present a relational algebra for declarative languages. It is based in the use of the operators of projection, selection, renaming, cross product, union and join. This relational algebra is an extension of the relational algebra for relational databases in the following sense. It uses "terms" in the sense of declarative languages instead of basic data like strings, integers, etc. In particular the projection and selection operators are modied and allow the projection of subterms of a given term and the selection of tuples of terms with respect to a boolean condition, which consists on an equality between terms. In other words, unication and pattern matching is replaced in the relational algebra by means of projection of subterms and selection w.r.t. a ground equality. This relational algebra can be used for de- ning predicates and functions for a declarative language, and in general for de- ning clauses and rewriting rules. This relational algebra will allow to recursively dene predicates and functions as views from tuples of ground terms. We will also provide a denotational and operational semantics for these relational operators, which can be used for de- ning the usual operational semantics of declarative semantics: resolution and rewriting. We are concerned to provide an operational semantics based on rewriting of algebra expressions. We will present soundness results of our operational semantics w.r.t. resolution and rewriting. A suitable rewriting strategy is out of the scope of the paper, which is considered as future work. Finally, we will present a SQL-based syntax based on this relational algebra. Basically, SQL syntax is extended with recursive predicate/function denitions in which functions and predicates are relations dened in terms of other relations or an special relation of tuples of ground terms. SQL syntax is also extended to handle terms in the sense of declarative languages in either projections or selections. The structure of the paper is as follow. Section 2 will introduce the basic ideas. Section 3 will present the case of logic programming. Section 4 will show the case of functional programming. Section 5 will introduce the SQL syntax. Finally, section 6 will conclude and present future work. 2. Preliminaries Given two relational tables including employers and employer tasks of a given company, in which we store the (id)entier, name and age of the employers, and each task for each employer: employers id name age tasks id task 1 peter john susan james the relation algebra can be used for expressing queries like retrieve the tasks for peter: π task (σ id=id2, (employers δ id id2 tasks)) name=peter

3 whose result is a table with a unique column called task and two elements (7) and (11). In this algebra expression, there is a cross product between employers and tasks relations, where the name of the column id in the relation tasks is renamed to id2 in order to be distinguished from the name id for the column of employers. In addition, there is a selection in the cross product in order to recover peter's tasks, and nally the tasks are projected Datalog In a Datalog program [1] predicates can be used for dening the tuples of a relation, and rules for expressing queries. For instance, the above relations can be dened as follows: employers employers(1,peter,30). employers(2,john,25). employers(3,susan,34). employers(4,james,44). tasks tasks(1,7). tasks(1,11). tasks(2,8). tasks(3,1). and we can request the same query like a logic rule: petertasks(z):-employers(x,peter,y), tasks(x,z). Basically, a projection is a head variable in a predicate (i.e. Z), the sharing of variables (i.e. X) is a join and the selection corresponds with the instantiation of a given argument (i.e. peter). Assuming the same database schema (i.e. name of columns or attribute names) in the Datalog program for the above relations, that is, employers(id, name, age) and tasks(id, task), the translation of the Datalog query is the same algebra expression. A comparison of Datalog queries and the relational algebra was studied in [1]. However, we would like to extend the cited translation to cover with logic programs in which no schema declaration is needed, function symbols are allowed (not allowed in Datalog programs) and no restrictions about variable occurrences exist (in Datalog a range restriction is required in clauses [1]). The lack of database schema in logic programming can be solved by supposing to name columns using the relation name (i.e. predicate name) and numbering columns (i.e. arguments) from left to right. For instance, in the case of the predicate employers, the name for the columns will be employers 1, employers 2, etc. Then the algebra expression would be now: π tasks 2 (employers employers 1 = tasks 1 employers 2 = peter tasks) In addition, each tuple of the database (i.e. each logic fact) can be seen as an algebra expression, considering tuples on terms as a particular case of algebra expressions and using the union operator. Therefore, employers and tasks relations are represented by means of the following algebra expressions: employers (1,peter,30) (2,john,25) (3,susan,34) (4,james,44) tasks (1,7) (1,11) (2,8) (3,1) We have solved the problem of schema declaration, however there are two additional problems to be solved: function symbols and non range restriction. They will solved later. Now, we would like to show how a functional language can be also expressed by means of the relational algebra. In a functional language the introduction of function symbols (i.e. called data constructors in a function setting), and non range restriction will be also required. Given that in both logic and functional programming the adopted solution is similar we will now introduce the case of functional programming Functional Programming In a functional language one could dene functions like: f(x) g(x). g(0) 0. In this case, f and g can be seen as relations, where g denes a tuple (0,0) representing the graph of the function (i.e. a pair argumentresult), and f can be seen as the following algebra expression: f := δ g 1 f 1,g 2 f 2 (g) Here, f denes the tuple (0,0) of schema (f 1,f 2) which is obtained from g by renaming columns (i.e. δ g 1 f 1,g 2 f 2 ). Now, the term f(0) to be reduced corresponds with the following algebra expression: π f 2 (σ f 1 =0 (f )) in which the requested argument is considered as a selection and the value of f(0) is a projection of the second column of the relation

4 dened by f. Using the denition of f, f(0) is equivalent to: π f 2 (σ f 1 =0 (δ g 1 f 1,g 2 f 2 (g))) which can be easily rewritten into (0) following the basic behavior of the algebra operators: π f 2 (σ f 1 =0 (δ g 1 f 1,g 2 f 2 ((0, 0 ) (g 1,g 2 )))) π f 2 (σ f 1 =0 ((0, 0 ) (f 1,f 2 ))) π f 2 ((0, 0 ) (f 1,f 2 )) (0 ) (f 2 ) Let us remark that tuples are labeled with the database schema (i.e. (g 1, g 2 ) and (f 1, f 2 )) when g is replaced by its graph in order to know in each step which is the current database schema. In functional languages functions can be nested. For instance, we can dene: f(x) g(x). g(0) 0. h(x) 0. and consider the term f(h(x)) to be reduced. Firstly, the rule for h can be dened as an algebra expression as follows: h := t TERM (t, 0 ) in which there is an (possibly) innite set of tuples dening h. The tuples have the form (t, 0 ) where t is a ground term. T ERM denotes the set of ground terms. This kind of expression motivates the introduction of the so-called term relations. Taking as starting point the set T ERM, we can build a relation called T which consists of unitary tuples of the form (t) where t T ERM. In other words, T = t T ERM (t). The database schema of T is T (term), that is, the unique column of the relation is called term. This is the simplest term relation. Now, we can build from T new term relations. For instance, the cross product: T... T. However in order not to confuse column names, as usual in the cross product operator, columns are renamed as follows: T n = δ term term1 (T )... δ term termn (T ) This term relation T n contains tuples which have the form (t 1,..., t n), where t i T ERM. This kind of term relation is the basis of our work. Logic and functional languages use clauses and rules for dening views from these term relations. For instance, the above function h denes the following view: h := δ term1 h 1,term 2 h 2 (σ term2 =0(δ term term1 (T ) δ term term2 (T ))) which is equivalent to h := t TERM (t, 0 ) (h 1,h 2 ). Now, the term f(h(x)) to be reduced corresponds with: π f 2 (σ f 1 =h 2 (f h)) in which the result of h (i.e. the second column of h) is the value required for f in the argument (i.e. the rst column). Therefore σ f 1 =h 2 (f h) is required. Function nestings correspond with joins (i.e. cross products together with selections) in our approach. Now, it can be rewritten as follows: π f 2 (σ f 1 =h 2 (δ g 1 f 1,g 2 f 2 ((0, 0 ) (g 1,g 2 )) t TERM (t, 0 ) (h 1,h 2 ))) π f 2 (σ f 1 =h 2 ((0, 0 ) (f 1,f 2 ) t T ERM (t, 0) (h 1,h 2))) π f 2 (σ f 1 =h 2 ( t TERM ((0, 0, t, 0 ))) π f 2 ( t TERM σ f 1 =h 2 ((0, 0, t, 0 ))) π f 2 ( t TERM ((0, 0, t, 0 ) (f 1,f 2,h 1,h 2 ))) (0 ) (f 2 ) However, the previous f and g dene more tuples than (0,0). According to the usual semantics of functional languages, they also denes tuples (t, ) for each term t. That is, actually the function f is dened as: f := (0, 0 ) t TERM (t, ) In other words, T ERM is the set of (possibly) innite ground terms with bottom according the usual semantics of functional languages. The above expression is equivalent to: f := δ term1 f 1,term 2 f 2 (σ term1 =0,term 2 =0(δ term term1 (T ) δ term term2 (T ))) δ term1 f 1,term 2 f 2 (σ term2 = (δ term term1 (T ) δ term term2 (T ))) assuming T ERM contains terms with bottom. In general, a function is dened by means of an (possibly) innite union of tuples, and in order to rewrite an algebra expression, we can use any of the elements of the union. In particular, elements of the kind (t, ) can be used for evaluating non-strict functions. For instance, with regard to: f(x) 0.

5 then f := t TERM (t, 0 ); and supposing g undened (i.e. g := t TERM (t, )), the term f(g(x)) to be reduced can be expressed as: π f 2 (σ f 1 =g 2 (f g) and rewritten as follows: π f 2 (σ f 1 =g 2 ( t TERM (t, 0 ) (f 1,f 2 ) t T ERM (t, ) (g 1,g 2))) π f 2 ( σ f 1 =g 2 ( t,t TERM ((t, 0 ) (f 1,f 2 ) (t, ) (g 1,g 2))) π f 2 ( t TERM ((, 0, t, ) (f 1,f 2,g 1,g 2 ))) (0 ) (f 2 ) Due to the range restriction Datalog programs do not need the introduction of the cited term relations. Range restriction ensures that Datalog programs dene relations by means of ground facts, and Datalog rules dene views from facts. In other words, Datalog deductive databases work with an intensional database dened by means of Datalog facts and extensional database dened by means of Datalog rules. When extending to logic programming, facts can include variables and logic rules can have head variables not occurring in the body. Therefore the extension of Datalog to logic programming forces the introduction of the term relation T as intensional database Handling Function Symbols and Data Constructors Now, we would like to extend our relational algebra to cope with data constructors (or function symbols in the logic programming context). For instance we can write the following set of rules: leq(0, X) true. leq(s(x), s(y )) leq(x, Y ). In this case, the function leq which denes the natural order between natural numbers can be expressed in the relational algebra as follows: leq := t TERM (0, t, true) δ s(leq 1) leq 1,s(leq 2) leq 2 (π s(leq 1),s(leq 2),leq 3(leq)) in which we use projection terms s(leq 1 ) and s(leq 2 ) whose meaning is to project s(t) for each term t of leq 1, and analogously for leq 2. Let us see an example of evaluation. For instance, we can suppose we have the term leq(s(0 ), s(s(0 ))) to be reduced, which corresponds with: π leq 3 (σ leq 1 =s(0 ),leq 2 =s(s(0 ))(leq)) and can be evaluated as follows: π leq 3 (σ leq 1 =s(0 ),leq 2 =s(s(0 ))(leq)) π leq 3 (σ leq 1 =s(0 ),leq 2 =s(s(0 ))( δ s(leq 1 ) leq 1,s(leq 2 ) leq 2 (π s(leq 1),s(leq 2),leq 3 (leq)))) π leq 3 (σ leq 1 =s(0 ),leq 2 =s(s(0 ))( δ s(leq 1 ) leq 1,s(leq 2 ) leq 2 (π s(leq 1 ),s(leq 2 ),leq 3 ( t T ERM (0, t, true) leq 1,leq 2,leq 3)))) π leq 3 (σ leq 1 =s(0 ),leq 2 =s(s(0 ))( t T ERM (s(0), s(t), true) leq 1,leq 2,leq 3))) π leq 3 ((s(0 ), s(s(0 )), true) leq 1,leq 2,leq 3 ))) (true) leq 3 Let us remark that in the rst step, the second component of the union dening leq is used, and the rst component of the union of leq is used in the second step. It simulates the selection of the rewriting rule in a functional language. The same kind of handling of data constructors is needed in the logic programming context for function symbols. Due to the use of constructors in projections, attribute or column names in output relations can also include constructors. For instance, the schema of the output relation of π s(leq 1),s(leq 2),leq 3(leq) is (s(leq 1), s(leq 2), leq 3). This is also one of the properties in which the relational algebra is extended in our work. In addition, selections can refer to equalities on terms, as in the case of leq 2 = s(s(0 )). In general, projections and selections can use the so-called relational terms containing attribute names instead of variables. For instance, in the case: append([], L) L. append([x L1], L2) [X append(l1, L2)]. where [_] and [_ _] are the list data constructors, we can express append in the relational algebra as follows: append := t TERM ([], t, t) δ (π [term append 1],append 2,[term append 3] (append T )) where = [term append 1] append 1, append 2 append 2, [term append 3] append 3. In the above expression, the second component of the union recursively denes a set of tuples of the form ([t s], s, [t s ]) whenever (s, s, s ) is a tuple of the same relation.

6 Finally, we also have to use destructors for each constructor. For instance, in the case: inlast(x, L) append(l, [X]). we have: inlast := δ (π [ ] 1 (append 2 ),append 1,append 3 (σ [ ] 2(append 2)=[]((append))). where = [ ] 1(append 2) inlast 1, append 1 inlast 2, append 3 inlast 3. In the above expression, the term [ ] 1 (append 2 ) is a destruction (i.e. projection) of the second argument of the function append w.r.t. the rst argument of the list constructor. [_ _] 1 allows the retrieval of t for each term of the form [t t ], and is undened for the empty list. In general, there are data destructors c.i, where 1 i n, for each constructor c of arity n, allowing the retrieval of each argument of a given constructor. In the case of [_ _], we can consider two destructors: [_ _] 1 for retrieving the list head and [_ _] 2 for retrieving the list tail. Similarly to the case of constructors, data destructors are also required for the extension of Datalog to logic programming. This is the case, for instance, of the logic version of previous inlast function. 3. Foundations In this section we will introduce the formal framework of our proposal. Firstly, we will de- ne relations on terms as domain for our relational algebra. Secondly, we will introduce the relational algebra and its operators: selection, projection, cross product, renaming and union. As usual, join is a combination of cross product and selection Relations on Terms Assuming a nite set of data constructors DC: c, d,... each one with an associated arity n 0, and in particular a subset of constants of arity zero (as special case, we consider a constant of arity zero), the set of data terms, denoted by T ERM, are (possibly innite) terms build from elements of DC { }. Substitutions θ = {X/t t T ERM} are nite maps from variables to data terms. In addition, given a nite set of relation names: p, q, r, s..., each one with an associated arity n > 0, the set of relational terms, denoted by RT ERM, are nite terms built from DC, constants of the form r.k for 1 k n, where n is the arity of r, and the set of data destructors DD of the form c.i of unary arity obtained from each c of DC for each 1 i n where n is the arity of c. We consider name bindings of the form ρ = {X/s s RT ERM} which are mappings of variables into relational terms. A term relation R of schema (s 1,..., s n) where s i are relational terms is a (possibly in- nite) set of tuples of data terms (t 1,..., t n). s i's are called attribute or column names of the term relation. There is an special case of term relation, denoted by T, a unary term relation with a unique attribute called term and containing as tuples elements of the form (t) for each data term t. In other words T = t T ERM (t). We denote by T n the term relation obtained as the n-cross product of T where T n δ term term1 (T )... δ term termn (T ) Algebra Operators Now, the algebra operators: selection, projection, cross product, union and renaming are dened for term relations as in table 1, where s i's are relational terms. In addition, the relation = R, where R is a term relation, which establishes when a tuple satises an equality between relational terms, is dened as follows: (t 1,..., t n) = R s i = s i i [s i] R (t 1,...,t n) = [s i] R (t 1,...,t n), and [s] R (t 1,...,t n) is dened as follows: [R k ] R (t 1,...,t n) = t k if R has schema (R 1,..., R n); otherwise, [c] R (t 1,...,t n) = c if c DC is a constant; [c(s 1,..., s m)] R (t 1,...,t n) = c([s 1] R (t 1,...,t n),..., [s m] R (t 1,...,t n)); [c.j(c(s 1,..., s m))] R (t 1,...,t n) = [s j] R (t 1,...,t m); and otherwise, [s] R (t 1,...,t n) =. For instance, given R = (s(leq 1 ), s(leq 2 ), leq 3 ) then [s 1 (s(leq 1))] R (s(0 ),s(0 ),true) = (0 ). Let us remark that algebra operators can obtain in general data terms with bottom, for instance:

7 Selection σ s1 =s 1,...,sm=s m (R) = def R Cuadro 1: Algebra Operators where R = {(t 1,..., t n) R (t 1,..., t n) = R s 1 = s 1,..., sm = s m } Projection π s1,...,sm (R) = def R where R = {(k 1,..., k m) [s 1 ] R (t 1,...,tn) = k 1,..., [s m] R (t 1,...,tn) = km, (t 1,..., t n) R} Cross Product R R = def R where R = {(t 1,..., t n, t 1,..., t m ) (t 1,..., t n) R, (t 1,..., t m ) R } Union R R = def R where R = {(t 1,..., t n) (t 1,..., t n) R} {(t 1,..., t n ) (t 1,..., t n ) R } and R, R have the same schema. Renaming δ s1 s 1,...,sn s (R) = R n where R has schema (s 1,..., s n ) whenever R has schema (s 1,..., s n), and they have the same tuples. R [s 1 (leq 1 )] (0,s(0 ),true) = ( ) whenever R = (leq 1, leq 2, leq 3). Therefore, we have to consider two semantics on the algebra expressions: the strict semantics in which algebra operators are only dened for term relations without bottom, and a more general semantics, the non-strict semantics in which we handle any kind of term relations. Finally, we assume the following convention. π term(σ term=s (T )) where s is a ground data term can be written as π s(t ), and δ term r(π term(σ term=s(t ))) where s is a ground data term can be written as δ s r(π s(t )). For instance π 0(T ) = (0) and δ 0 p(π 0(T )) = (0) p. 4. Logic Programming Logic programming can be considered as a data denition language in which relations are dened by means of the union operator, and each element of the union consists of a view from T n. In order to give a precise formulation of this claim, we will translate each logic program into an algebra expression. Assuming two sets: P of predicate names, and DC of data constructors or function symbols, we consider logic programs built from P and DC Mapping Literals into the Algebra Now, each literal p(t 1,..., t n) can be mapped into three elements: a selection, a projection, and a name binding (i.e a binding of variables into relational terms). It can be computed with the following algorithm SP taking as input a term relation R and a sequence of data terms with variables < t 1,..., t n > and returning Sel: is a set of equalities between relational terms, P roj: is a sequence of relational terms, and ρ: a name binding. SP (R, < t 1,..., t n >) = (Sel, P roj, ρ) is computed as follows: (a) SP (R, < t 1,..., t n > ) = ( 1 i n Sel i, 1 i n P roj i, ρ 1... ρ n) where: (a.1) (Sel i, P roj i, ρ i) = SP (R, t i, i); (a.2) 1 i n P roj i is the concatenation of the sequences P roj 1,..., P roj n; and (a.3) ρ 1... ρ n is the composition of name bindings. In addition, (b) SP (R, t, i), where R has schema (s 1,..., s n), is dened as: (b.1) SP (R, X, i) = ({}, < s i >, {X/s i}) if X is a variable; (b.2) SP (R, t, i) = ({s i = t}, ɛ, {}) if t is ground; and (b.3) SP (R, c(t 1,..., t n), i) = ( 1 j n {c.j(t) = t t = t Sel j}, 1 j n < c.j(p roj j) >, ρ 1... ρ n) if c(t 1,..., t n) is not ground, where (Sel j, P roj j, ρ j) = SP (R, t j, i), 1 j n. For instance, for R = p of schema (p 1, p 2 ) (therefore the literal is p(0, f(x, Y )) then SP(p, < 0, f(x, Y ) >) = ({p 1 = 0}, < f 1(p 2), f 2(p 2) >, {X/p 2, Y/p 2}).

8 4.2. Mapping Clauses into the Algebra Now, a rule p( t) : q 1( s 1),..., q k ( s k ) can be translated as follows. Let the relation be R = δ 1(q 1)... δ k (q k ) where δ i is a renaming of the attribute names of q i whenever there exists q j = q i for i j or q i = p. Let SP (R, < s 1,..., s k >) = (Sel, P roj, ρ) be and let {X 1,..., X l } be the set of variables of {t 1,..., t n} not occurring in the rule body; in addition, let the mapping be ρ 0 = {X 1/term 1,..., X l /term l }, and nally, let ρ r = ρ ρ 0 be, then the translation is: p := δ t1 ρ r p 1,...,t nρ r p.n(π t1 ρ r,...,t nρ r (σ Sel (R T l )). For instance, p(0, X ) : q(x ), r(x ) can be translated as follows. Given that R = q r, then SP(R, < X, X >) = ({q 1 = r 1 }, < q 1 >, {X /q 1 }), and therefore p := δ 0,q 1 p 1,p 2 (π 0,q 1 ((σ q 1 =r 1 (q r T )))). This algebra expression is equivalent (following the assumed conventions) to p := δ 0,q 1 p 1,p 2 ((0 ) π q 1 ((σ q 1 =r 1 (q r)))). Analogously, in the case of p(y, f (X )) : r(x ), r(y ): R = r δ r 1 r 1 (r) and SP(R, < X, Y >) = ({}, < r 1, f (r 1 ) >, {X/r 1, Y/r 1 }) and therefore p := δ r 1,f 1 (r 1 ) p 1,p 2 (π r 1,f 1 (r 1 )(r δ r 1 r 1 (r)))). Now, a fact p(t 1,..., t n) can be translated as follows. Let {X 1,..., X k } be the set of variables of {t 1,..., t n} and let the mapping be ρ = {X 1/term 1,..., X k /term k }, then the translation is p := δ t1 ρ p 1...t nρ p.n(π t1 ρ,...,t nρ(t k )). For instance, p(0, s(x )) is translated into p := δ 0 p 1,s(term) p 2 (π 0,s(term) (T )) which is equivalent to δ 0 p 1,s(term) p 2 ((0 ) π s(term) (T )). This algebra expression is also equivalent to t T ERM (0, s(t)) (p 1,p 2). Analogously, p(x, Y ) which is translated into p := δ term1 p 1,term 2 p 2 (π term1,term 2 (T 2 )). This algebra expression is also equivalent to t T ERM,t T ERM (t, t ) (p 1,p 2). A set of clauses for a predicate can be translated into an algebra expression by considering the union of the algebra expressions obtained from the previous translation. A program is translated by mapping each predicate of the program into an algebra expression. The translation of a program P is denoted by A(P) Mapping Goals into the Algebra Finally, a goal : q 1( s 1),..., q k ( s k ) can be translated as follows. Let R = δ 1(q 1)... δ k (q k ) as previously, and let SP (R, < s 1,..., s k >) = (Sel, P roj, ρ) be, then the translation is π P roj(σ Sel (R)). For instance, the goal : q(x, 0), p(x) is translated as follows. SP(q p, < X, 0, X > ) = ({q 2 = 0, p 1 = q 1 }, < q 1 > {X/q 1}) and the goal is translated into π q 1 (σ q 2 =0,p 1 =q 1 (p q)) Answers Now, an answer to a goal : q 1( s 1),..., q k ( s k ) is a tuple of data terms (t 1,..., t l ) such that (t 1,..., t l ) π P roj(σ Sel (R)) under an strict semantics, where R = δ 1(q 1)... δ k (q k ) is as previously. Theorem 4.1 (Soundness) (t 1,..., t l ) is an answer of π P roj(σ Sel (δ 1(q 1)... δ k (q k ))) w.r.t. i there exists θ such that X iθ = t i for each X i V ar(q 1( s 1),..., q k ( s k )) and θ is a ground computed answer of q 1( s 1),..., q k ( s k ) w.r.t. P. 5. Functional Programming First-order functional programming can be seen as an instance of our framework. The core of a rst-order functional language is a term rewriting system in which the behavior of functions is dened. In our framework, function de- nitions by means of a term rewriting system will also represent views from the database of tuples of ground terms. We will follow the standard framework of term rewriting [3] Mapping terms into the Algebra A term t can be mapped into a selection and a name binding. In order to provide such mapping, rstly, we need to proceed with the unnesting of terms. This unnesting process will give us a data term and a set of equations eq. This process is similar to let introduction

9 in a functional language. The equations have the form X = t where X is a variable and t is a at term. A at term is a non-variable data term or has the form f(x 1,..., X n) with f F. The unnesting process is computed with the algorithm: unnest(t) = (t, eq) dened as follows: (a) If t X then return (X, {}); (b) If t t, t is ground without dened symbols, then return (t, {}); (c) If t c(t 1,..., t n), c DC then return (c(x 1,..., X n), 1 i n {X i = t i} 1 i n eq i) where unnest(t i) = (t i, eq i), 1 i n, and X i's are fresh variables; (d) If t f(t 1,..., t n), f F, then return (X, 1 i n {X = f(x 1,..., X n), X i = t i} 1 i n eq i) where unnest(t i) = (t i, eq i), 1 i n, and X i's, X are fresh variables. For instance, unnest(f (g(h(s(0 ))))) = (Y, {U = s(0 ), Z = h(u ), X = g(z ), Y = f (X )}), and unnest(s(f (g(x, s(x ))))) = (s(y ), {Z = g(x, T ), T = s(x), Y = f(z)}). Now, given a data term t and a set of equations of the form X = t where X is a variable and t is a at term then the algorithm T E(t, eq) produces a selection Sel, a name binding ρ, and a set of function symbols R. T E(t, eq) = (Sel, ρ, R) is computed as follows: (a) T E(t, eq) = (Sel, ρ, R) where Sel = ( 1 i n Sel i)ρ, ρ = ρ 1... ρ n, R = 1 i n R i, and eq = {X 1 = t 1,..., X n = t n}, T E(t, X i = t i) = (Sel i, ρ i, R i), 1 i n. In addition, (b) T E(s, X = t) = (Sel, ρ, R) is dened as follows: (b.1) If t is ground without dened symbols, then Sel = {X = t}, ρ = {} and R = {}; (b.2) If t = c(x 1,..., X n), c DC then Sel = {X 1 = c 1(X),..., X n = c.n(x)}, ρ = {} and R = {}; (b.3) If t = f(x 1,..., X n), X / var(s), f F then Sel = {X = r n+1}, ρ = {X 1/r 1,..., X n/r n} and R = {δ f 1,...,f.n r 1,...,r n (f)}; (b.4) If t = f(x 1,..., X n), X var(s), f F then Sel = {}, ρ = {X 1/r 1,..., X n/r n, X/r n+1} and R = {δ f 1,...,f.n r 1,...,r n (f)}. For instance, T E(Y, {U = s(0), Z = h(u), X = g(z), Y = f(x)}) = ({h 1 = s(0), g 1 = h 2, f 1 = g 2}, {U/h 1, Z/g 1, X/f 1, Y/f 2}, {h, g, f}), and T E(s(Y ), {Z = g(x, T ), T = s(x), Y = f(z)}) = ({f 1 = g 3, g 1 = s 1(g 2)}, {X/g 1, T/g 2, Z/f 1, Y/f 2}, {g, f}). Let us remark that in the above (b.3) and (b.4) steps, function schemas are renamed in order not to confuse several occurrences of the same function symbol. However, in the presented examples it is not needed Mapping Rewriting Rules into the Algebra Given a rewriting rule l r of a constructor-based TRS, l r can be mapped into an algebra expression as follows. Let (r, eq) = unnest(r), (Sel, ρ, R) = T E(r, eq), l = f(s 1,..., s n) be and let {X 1,..., X l } be the variables occurring in l but not in r, then the translation is: f := δ s1 ρ r f 1,...s nρ r f.n,r f.n+1 (π s1 ρ r,...s nρ r,r ρ(σ Sel (R T l )) δ term1 f 1,...,term n+1 f.n+1 (π term1,...,term n+1 (σ termn+1 = (T n+1 ))) where ρ r = ρ ρ 0, ρ 0 = {X 1/term 1,..., X l /term l }. We denote by T f,n = δ term1 f 1,...,term n+1 f.n+1 (π term1,...,term n+1 (σ termn+1 = (T n+1 ))) For instance, the translation of h(x) f(g(h(s(0)))) is: h := δ term1 h 1,f 3 h 2 (π term,f 3(σ h 1=s(0),g 1=h 2,f 1=g 2 (f h g T ))) T h,1 where T h,1 is equivalent to t T ERM (t, ) (h 1,h 2). Analogously, h(x) s(f(g(x, s(x)))) is translated into h := δ g 1 h 1,s(f 2) h 2 (π g 1,s(f 2)((σ f 1=g 3,g 1=s 1(g 2)(f g))) T h,1 A set of rewriting rules for a function symbol is translated by considering the union of algebra expressions for each rewriting rule. A TRS is translated by mapping each function symbol dened by means of the TRS. The translation is denoted by A(T RS) Mapping Terms into the Algebra Now, given a term t to be reduced, the translation of t is as follows. Let (t, eq) = unnest(t) and (Sel, ρ, R) = T E(t, eq) be; in

10 addition, let {X 1,..., X l } be the variables of t occurring out of the scope of a function symbol and ρ 0 = {X 1/term 1,..., X l /term l }; then the translation is: π t ρ t (σ Sel (R T l )) where ρ t = ρ ρ 0. For instance, f(g(0, s(0))) is translated into π f 2(σ f 1=g 3,g 1=0,g 2=s(0)(f g)) Theorem 5.1 Soundness Given a term t and s T ERM without bottom, then (s) π t ρ t (σ Sel (R T l )) w.r.t. A(T RS) under nonstrict semantics i t evaluates to s w.r.t. T RS. Let us remark that under a non-strict semantics, the rewriting of algebra expressions can lead to terms with bottom, however, they do not represent a successful reduction, rather than they represent an unsuccessful one. This is the reason the previous theorem restricts to terms without bottom. 6. SQL Syntax Finally, we would like to present a SQL syntax based on our relational algebra. Predicates are dened by means of a createpred statement and a function symbol by means of a createfun statement: P ::= createpred Name as Q 1 union... Q n F ::= createfun Name as Q 1 union... Q n Q ::= select s 1... s n from TERM 1... TERM l, g 1... g k where r 1 = r 1 and... r m = r m where s's, r's are relational terms, and g's are predicates or functions. 7. Conclusions and Future work This work opens two promising extensions. The extended relational algebra can be the basis of an abstract machine which can be used for implementing declarative languages. Furthermore, the handling of a database in a declarative language can be implemented using a database manager. This formalism can be also used for studying code optimizations based on properties of the algebra operators and, in general, it can be used for analyzing, transforming and specializing declarative programs. Referencias [1] S. Abiteboul, R. Hull, and V. Vianu. Foundations of Databases. Addison- Wesley, [2] J. M. Almendros-Jiménez and A. Becerra-Terón. Database Query Languages and Functional Logic Programming. New Generation Computing, 24(2):129184, [3] F. Baader and T.Nipkow. Term Rewriting and All That. Cambridge University Press, [4] A. Belussi, E. Bertino, and B. Catania. An Extended Algebra for Constraint Databases. IEEE Transactions on Knowledge and Data Engineering, TK- DE, 10(5):686705, [5] E. F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, CACM, 13(6): , [6] M. Fernández, J. Simeon, and P. Wadler. An Algebra for XML Query. In Proc. of Foundation of Software Technology and Theoretical Computer Science, FSTTCS, LNCS 1974, pages Springer, [7] P. Kanellakis and D. Goldin. Constraint Query Algebras. Constraints, 1(12):45 83, [8] J. W. Lloyd. Foundations of Logic Programming. Springer, [9] L. E. McKenzie and R. T. Snodgrass. Evaluation of Relational Algebras Incorporating the Time Dimension in Databases. ACM Computing Surveys, 4(23): , [10] G. M. Shaw and S. B. Zdonik. An Object- Oriented Query Algebra. In Proceedings of the Second International Workshop on Database Programming Languages, DBPL'89, pages Morgan Kaufmann, 1989.