Sellers whose information content is defined by the attributes S-NAME and ..... The component Domf associates a domain with each atomic-valued attribute i.e. ...
1 How to cite this publication: Niemi, T. & Järvelin, K. (1996). The processing strategy for the NF2 relational FRC-interface. Information & Software Technology 38 1996: 11-24.
THE PROCESSING STRATEGY FOR THE NF 2 RELATIONAL FRC-INTERFACE Timo Niemi# and Kalervo Järvelin+ #Dept. of Computer Science and +Dept. of Information Studies University of Tampere P.O.Box 607 FIN-33101 TAMPERE, Finland SUMMARY It has been widely recognized that the proposed user-oriented NF2 (Non-First-Normal-Form) relational query languages such as different SQL extensions are cumbersome to use from view point of an ordinary end-user. This is because the user usually has to formulate large nested expressions in order to specify how the result NF2 relation is derived from the source NF2 relation(s). The NF2 relational query interface in this paper is based on a different approach. In it the user describes only the structure of the result NF2 relation in a straightforward and intuitive way. This starting point of our interface affords the possibility of formulating queries in a compact and truly declarative manner - also in those cases which require considerable restructuring among data. In this paper we consider the Prolog-based implementation of the query processing strategy of our interface. Special attention is paid to those principles and techniques in terms of which the representation and manipulation of complex structural relationships of NF2 relations can be managed in Prolog. KEY WORDS NF2 relational model User interface Query processing Logic programming Prolog-based knowledge representation
INTRODUCTION Informally, we can say that complex entities in the real world are entities which consist of other entities. In representing complex entities by the conventional relational model it is usual that they have to be distributed over several relations. This is unintuitive and in many applications there is a strong need to represent a complex entity as a whole. The NF2 (NonFirst-Normal-Form) relations are relations which contain both atomic-valued and relationvalued attributes. In other words they may have other relations as attribute values which, in turn, may have relations as attribute values and so on. Because NF2 relations allow relations within relations they are often called also nested relations. In terms of relationvalued attributes of NF2 relations it is possible to represent complex hierarchies and thus NF2 relations are also an alternative to represent a complex entity as a whole. In practice, in many applications it is important that hierarchical relationships among subentities, of which the entity at hand consists, can be represented explicitly. Therefore NF2 relations have been proposed for representing complex entities in many advanced applications such as in office automation,1 DBMIRS (Database Management and Information Retrieval Systems),2-3 design of electronic components,4 CIM (Computer Integrated Manufacturing),5 robotics6-7 and temporal data management.8 Also, in many conventional database applications hierarchical relationships are needed in the description
2 of real world entities. Especially the need to represent query results on the basis of the NF2 relational model is obvious. The NF2 relational model contains similar operations as the conventional relational algebra (only modified to manipulate NF2 relations) and in addition two restructuring operations: nest and unnest. The nest operation adds one level of nesting (or hierarchy) to an NF2 relation whereas the unnest operation flattens an NF2 relation by one level. In fact it has been proven that the same information content can be extracted by the NF2 relational algebra and the conventional relational algebra defined for 1NF (First Normal Form) relations i.e. they have the same expressive power.9 The NF2 relational model is actually needed because its structural expressiveness is much larger than the conventional relational model. Due to this fact the NF2 relational model has a closer connection to databases organized according to hierarchical or network data models. In 10 we have shown how hierarchical databases can be represented as NF2 relations and in 11 it has been shown how NF2 relations can be produced from network databases by navigating links. So far the dominating approach to allowing NF2 relational queries for the end user is to make extensions 4-5,12-14 of SQL (see e.g. 15 ). It has been widely recognized (see e.g. 5) that query formulation, from the view point of the ordinary end user, is troublesome with these extended SQL languages. In fact , very often the NF2 relational query formulation with an extended SQL resembles rather the design of an algorithm than a non-procedural specification. Our goal in this paper is to introduce such a query interface which minimizes the user effort in query formulation. We demonstrate that query formulation remains simple, compact and truly declarative - also in the context of complex queries. The query processing strategy has been developed so that it is also applicable to main memory implementation. In 16 the query processing strategy of our interface has been defined formally - independent of any programming language. Here we describe its Prolog-based implementation. It is characteristic of our issue in this paper that we have to manipulate complex structural relationships among data. Therefore we recall first our structural objects 17 in terms of which it is possible to manage complex structural modeling in a Prolog environment. Next we define a calculus consisting of two construction operations on the basis of which the structural transformations among data are performed during query processing. The construction operations manipulate structures, called nf2 -structures, which are represented in terms of the structural objects. In this context we pay special attention to the Prologbased representation of an NF2 relation constructed by our calculus. After that, in the next two sections we introduce our query interface and describe the Prolog-based implementation of the query processing strategy based on it. In the second last section we consider the implementation of our query processing strategy in the case that several NF2 relations have to be processed in a query. Finally we discuss features of our implementation and its role in our deductive database system. Throughout the paper we assume that the reader is familiar both with Prolog and databases.
THE REPRESENTATIONS OF STRUCTURAL OBJECTS IN PROLOG It is typical of Prolog that it defines the semantic interpretation of a program in two ways: declarative semantics inherited from logic and traditional procedural semantics. However Prolog is not only a means to specify the semantics of an application generally, precisely
3 and uniquely but it is, above all, a practical programming language. Prolog is based on logical rules in the formulation of which function symbols can be used. This in turn means that Prolog has the expressive power a Turing machine, i.e. any computation, which can be written in conventional programming languages, can also be expressed in Prolog. From the view point of logic Prolog is a subset of First Order Logic in terms of which recursive Horn clauses can be defined 18. Therefore our approach can also be seen as a logic-oriented way of implementing an NF2 relational query language. In our implementation we also use cut operations in order to process Prolog rules efficiently. Because the cut is an extra-logical predicate the side effect of its use is a deviation from the pure first order logic. The implementation of the NF2 relational query interface just in Prolog is interesting because the database and logic programming areas are merging fast together. This is due, among others, to the fact that the relational model and Prolog have a common theoretical foundation. Many authors (see e.g. 19-22) have proposed Prolog as a query language for formulating queries in deductive databases because it can be used to define both complex derived information and traditional database processing. It has also been used for several other purposes in the database area such as for implementing conventional relational query languages 23, processing normal forms in relational database design 24, converting relational query languages in a heterogeneous distributed database system 25 and getting access to data stored in Codasyl or Functional Data Model databases 26. We chose also Prolog as our implementation language because it has been widely recognized (e.g. 27) that it is an excellent tool for prototyping and it in itself supports the manipulation of functional expressions. There are many logic-based systems e.g. Datalog programs 15,28 which do not allow function symbols as their arguments. The capability of processing functions as arguments is in our approach, as we shall see, necessary because the structure of the result relation is described as a nested term (function). Furthermore many of our meta-rules17 defined to manipulate structural objects presuppose functions as arguments. There are many applications in which the management of structural aspects is essential. Therefore many advanced specification (e.g. VDM29,30, Z31) methods support modelling of large and structurally complex abstractions by offering for the user a large collection of different data types. In 32 we have considered how Prolog programs can be constructed on the basis of the VDM specification process. Complex structural relationships among data have a central role in database applications. Therefore we need strong general means and principles for structuring data in these applications. These kinds of tools have been included in the specification languages (e.g. ADABTPL33, Machiavelli34) tailored to database applications. Likewise one of the main ideas of object-oriented databases is to provide a collection of built-in structural data types which are used to model complex objects. Both in the abstract data type mechanism and object-oriented database systems complex objects are defined by applying some operations or constructors to structurally simpler objects. For example, in 35,36 more complex objects are constructed from atomic objects by applying to them recursively tuple and set constructors. We can characterize this kind of an approach as an object-based way to structure knowledge.
4 Also we use an object-based way to structure knowledge in Prolog to support systematic and structurally clear implementation. We want to stress that in this paper we do not implement an object-oriented database system. In other words we do not deal here with such topics as inheritance mechanisms, information passing paradigms and other issues related to object-oriented databases.37 Of course Prolog can also be used to implement object-oriented databases but this is not our intention. We only apply an object-based way to structure knowledge. In any object-based structuring mechanism, objects which have no structure from the view point of the system being constructed are called atoms or constants. Those objects, which can have other objects as components, are called compound structural objects. Each compound structural object is organized according to some structural type. In an objectbased structuring mechanism we have a set of primitive operations for each structural type. This means that in the manipulation of any compound structural object we can apply all primitive operations of the type according to which the compound structural object has been organized. From the view point of the object-based structuring mechanism it is essential that the number of available structural types is large enough for modelling all structural aspects related to the system being constructed. In the database applications we have observed that we have to pay attention to two essential points when making structural abstractions. First we have to analyze whether the object at hand consists of structurally homogeneous components. Second we have to know whether the order among components is important or not. In order to find a suitable structural abstraction we use intuitively the following rules. • If the object being abstracted consists of structurally homogeneous components among whose components the order is not important then the object is modelled as a set. • If the object being abstracted consists of structurally homogeneous components among whose components the order is important then the object is modelled as a tuple. • If the object being abstracted consists of structurally heterogeneous components then the object is modelled as a tree. In this case the order among components is always important because the manipulation of components, due to heterogeneity, cannot be based on one uniform way. • If we have to connect a collection of objects, which are structurally homogeneous with each other, to a collection of some other objects, which are again structurally homogeneous with each other, then the whole abstraction is modelled as a map object. We have shown that in terms of the above (four) structural object types it is possible to model structurally all knowledge which is needed in large and complex database applications. We have demonstrated that the above structural object types are sufficient to model relational databases17, entity-based user interface38,39 and data for transitive processing40,41. One of the basic ideas in the NF2 relational model is to allow the representation of complex real world entities as a whole. Now we will show that the complex structural relationships among data of NF2 relations can also be modelled with these structural objects. It is typical of Prolog that it is based on a few strong concepts. This means, among others, that all knowledge must be represented as a logical term because it is the only data structure accepted by Prolog. From the view point of Prolog it does not matter how complex these terms are. In other words in a standard Prolog environment the above structural object types have to be represented in terms of lists and compound terms. In17,42 we have introduced how the above structural data types can be represented as some legal Prolog
5 terms in any standard Prolog environment. This means that any combination of these structural objects is also a legal term executable by Prolog. For each structural type we have defined a set of primitive operations, called meta-rules.17 In fact the meta-rules are predefined predicates which can be applied to objects belonging to a specific structural type. Now we recall briefly the representational conventions for set, tuple, tree and map objects. In the same context we introduce only a few meta-rules, including those used elsewhere in the text. An interested reader finds a larger collection of meta-rules in 17,42. Set objects Standard Prolog implementations do not support sets as their own syntactical structures. However sets are very useful data structures in many contexts. Therefore e.g. the LDL (Logic-based Data Language) 43,44, which is also based on Horn clauses, allows sets as primitive objects in specifying rules and facts. This presupposes that the unification process has to be extended by a facility to perform unification on set. Because this feature does not belong to the standard Prolog we, as many other authors (see e.g. 18,45), emulate sets with lists. The only difference is that we think this representation rather as a collection of structurally homogeneous elements than as a list. For this structural type the conventional set operations such as the intersection, difference and union of two sets have been defined by the meta-rules set_union(Set1,Set2,Set3), set_intersection(Set1,Set2,Set3) and set_difference(Set1,Set2,Set3). Thus the goal set_union([a,b,c],[b,d],S) has the solution S = [a,c,b,d]. It is worth noting that the term [[a,b],d, [c,d,e]] is not in our sense a set object although it is a legal Prolog term. This is because it consists of structurally heterogeneous components (an atom and two set objects). Tuple objects Legal Prolog representations for tuple objects are generated by the following BNF. → t({,}*) → In other words a tuple object is a compound term whose functor name is mnemonically t. In addition, all components in the term t are assumed to be structurally of the same type. For example, t(a,b), t(t(a,b),t(d,e,f)) and t([c,d],[e,f],[g,e]) are three legal tuple representations because their components are structurally homogeneous, consisting of atoms, tuples and sets or lists, respectively. Instead, the term t(a,t(b,c), [d,e]) is not a tuple object even if it is a legal Prolog term. This is because it contains structurally heterogeneous objects (an atom, a tuple object and a set object). For example, the meta-rules tupleconcatenation and tupleprojection have been defined for this type. The meta-rule tupleconcatenation(Tuple1,Tuple2,Tuple3) concatenates two tuple objects Tuple1 and Tuple2 into one tuple object Tuple3. Thus, tupleconcatenation(t(a,b,c), t(d,e), Tuple) has the solution Tuple = t(a,b,c,d,e). The meta-rule tupleprojection(Tuple1,Index_list,Tuple2) constructs a tuple object Tuple2 from a given tuple object Tuple1 by projecting on the components indicated by the argument Index_list i.e. tupleprojection(t(a,b,c,d,e),[2,5],Tuple) has the solution Tuple = t(b,e). Tree objects
6
We can model a tree directly as a compound term of Prolog. We must not use t as a functor name because it is reserved for tuples. This modelling way means also that we have many ready primitive operations available for tree objects because we can utilize all Prolog system predicates intended for analysing and manipulating compound terms. For example, functor and arg are these kinds of system predicates. Structural abstractions can also contain tree objects which need not be identified by their own names. We call these kinds of tree objects anonymous tree objects. Syntactically anonymous tree objects are represented either as a compound term without expressing its functor name or the atom tree is used as its functor name. For example, (a,t(b,d),[f,g]) and tree(a,t(b,d),[f,g]) would be representations for anonymous tree objects whereas e.g. xyz(a,t(b,d),[f,g]) would be a named tree object. Map objects The following BNF generates legal Prolog representations for map objects. → [{, }*] | [ ] → (, ) → → → In addition we assume that the is same in all separate components. Furthermore all components with each other and all components with each other have to be structurally homogeneous in any map object. In other words a map object can explicitly be expressed as [f(do1,ro1), ... , f(don,ron)] where - f is a map indicator, - do1, ... ,don are domain elements and - ro1, ... ,ron are range elements. In [NiJä-93] we have considered the mathematical counterparts of different kinds of map objects. For example, the meta-rules dom_range(Map,Dom,Rng) and maps(Dom_element, Rng_element,Map) have been intended for manipulating map objects. The meta-rule dom_range constructs the domain elements (the argument Dom) and the range elements (the argument Rng) from a given map object (the argument Map). For example, dom_range([i_function(a1,t(1,2,1)),i_function(a2,t(1,2,2)),i_function(a3,t(1))],X,Y) gives the solutions X = [a1,a2,a3] and Y = [t(1,2,1),t(1,2,2),t(1)]. The meta-rule maps is able to produce both a range element associated with a domain element and a domain element associated with a range element in a given map object. For example, the goals maps(a2,Y,[i_function(a1,t(1,2,1)),i_function(a2,t(1,2,2)),i_function(a3,t(1))]) and maps(X,t(1,2,2),[i_function(a1,t(1,2,1)),i_function(a2,t(1,2,2)),i_function(a3,t(1))]) have the solutions Y = t(1,2,2) and X = a2. THE CALCULUS FOR MANIPULATING NF2 RELATIONS One approach to managing the construction of complex structural relationships among data is to develop a calculus for it. For example, in 35,36 a calculus consists of tuple and set
7 constructors and complex objects are constructed from atomic objects by applying these constructors recursively to them. In 14 these structural alternatives are extended by a list constructor. Also we develop a calculus for constructing NF2 relations in this paper. This calculus has a central role in our query processing mechanism. Our calculus is defined so that it is able to construct any arbitrary substructures, called nf2structures, of an NF2relation (also an nf2-structure). We utilize our calculus during query processing often so that subnf2-structures of the nf2-structure at hand are manipulated independently of each other and after that the results of these manipulations, which are also nf2-structures, are constructed to one nf2-structure by some operation of the calculus. In the database area there are two main abstraction levels: the schema and instance level. The schema level describes how the data are organized and the instance level contains the actual data which conform to the schema. In the context of the relational model we showed that the conventional instance-oriented Prolog representations of relations lead easily to definitions which are not theoretically sound.17 In addition these definitions are bound to some sample relations and desirable data independence is lost. The same observations concern also NF2 relations because a relation of the conventional relational model is structurally only a special case of NF2 relations. In order to avoid the above disadvantages we have to develop such a knowledge representation for NF2 relations (and thus for nf2 structures) which represents the schema and instance levels explicitly and binds them together in a natural and precise way. Our calculus is defined so that it satisfies these requirements. In our calculus the representation of nf2 -structures has the following starting points. • All information needed in the representation of nf2-structures is modelled as structural objects introduced above. This affords the possibility of defining and manipulating nf2-structures in a systematic and structurally clear way. In addition, we can apply our powerful meta-rules to these structural objects. • A unique name has to be given for each atomic-valued or relation-valued attribute. Attribute names are always some Prolog atoms in the structural sense. • In order to be able to analyze and manipulate nf2-structures we have to know which attribute names are related to atomic-valued or relation-valued attributes. • In any nf2-structure it is very important to know what structural relationships prevail among its different attributes. For this we will use indices. Structurally indices are tuples which consists of positive integers. • The instance level is constructed so that the values of atomic-valued attributes are represented as Prolog atoms whereas the values of relation-valued attributes are represented as set objects. If the nf2-structure at hand contains both atomic-valued and relation-valued attributes on its uppermost level then its instance is represented as a tree object because it consists of structurally heterogeneous components. • The representation has to include a mechanism for manipulating instances of any attribute - independent of its type.
8
In our calculus an nf2-structure is represented structurally as an anonymous tree object ((Rn,Indf),Inst) where a tree object (Rn,Indf) represents the schema and the object Inst the instance which, as we shall see, has several structural alternatives. The component Rn is a set object expressing the names of those relations which are included in the nf2-structure at hand. The component Indf is called an index function. It is a map object which associates a unique index with each atomic-valued and relation-valued attribute name. The structural relationships among attributes of an nf2-structure are expressed with indices. We define our calculus according to the following principles (A - C). A) The number of the construction operations in it must be sufficient. This means that in terms of them an NF2 relation or any of its substructures can be constructed by beginning from the representations of the smallest data units (i.e. atomic-valued attributes) in the NF2 relational model. B) On the other hand the number of the construction operations should be minimal. This is important because it supports the management of complex relationships in constructing nf2-structures. We show that only two construction operations are needed to form an NF2 relation from atomic-valued attribute representations. C) The construction operations must have the closure property. This means that both the source structures and the result structure of an operation have to be some nf2-structures. The closure property gives a good starting point to manipulate nf2-structures recursively in a natural way. In the calculus for manipulating nf2-structures we need the concept "nf2-structures of the same type" and it is defined as follows. Definition: The nf2-structures ((Rn,Indf),Inst1), ((Rn,Indf),Inst2), ... , ((Rn,Indf),Instn) are of the same type. In other words they have the same schema but their instances can be different. In our calculus we need a notation for empty nf2-structures. In our calculus an empty nf2structure is denoted by the Prolog atom lambda. This means that we have to define how the empty nf2-structure behaves in the context of the construction operations of the calculus. Definition of the calculus An nf2-structure is either lambda (the empty nf2-structure) or an anonymous tree object which is constructed by applying the following Prolog rules (1-3) finitely. (1) The atomic-valued attribute representation is the nf2-structure (([],[indf(a,t(1))]),t(v)) where - the atom a denotes an atomic-valued attribute name, - the atom v denotes a value of this attribute, - [] indicates that no relation-valued attribute is included in an nf2-structure of this type and - t(1) expresses the index associated with the attribute name a.
9 (2) The rule concate_NF2(NF2_STRUCT1, NF2_STRUCT2, NF2_STRUCT3) concatenates two nf2-structures NF2_STRUCT1 and NF2_STRUCT2 into one nf2-structure NF2_STRUCT3 (See the exact definition in the Appendix A). The rule constructs NF2_STRUCT3 so that the attributes included in NF2_STRUCT1 are indexed similarly in it. Instead, the attributes included in NF2_STRUCT2 are reindexed so that the greatest number, which appears as the first component in the indices of NF2_STRUCT1, is added to the first index component of the indices in NF2_STRUCT2. The rule constructs the instance of NF2_STRUCT3 by taking into account whether the instances of NF2_STRUCT1 and NF2_STRUCT2 are structurally homogeneous or heterogeneous. (3) If NF2_SET = [((Rn,Indf),Inst1),((Rn,Indf),Inst2), ... ,((Rn,Indf),Instn)] is a set consisting of n nf2-structures of the same type and R is an attribute name, which appears neither as relation-valued attribute name nor atomic-valued attribute name in the schema (Rn,Indf), then the rule relation_constructor(R,NF2_SET,RELATION) constructs the nf2structure RELATION from NF2_SET. RELATION represents a value of the relation-valued attribute R. The Prolog definition of the construction rule relation_constructor can be found in the Appendix A. The rule (3) associates the index t(1) with R in RELATION. The index function of RELATION is constructed from Indf by placing 1 to the first component in indices. Other components in the indices are as in Indf. The instance of RELATION is a set object [Inst1,Inst2, ... ,Instn]. For example, the rule concate_NF2((([],[indf(s_name,t(1))]),t(seller1)), (([], [indf(s_code, t(1))]),t(2)),NF2_STRUCTURE) concatenates two atomic-valued attribute representations into one nf2-structure NF2_STRUCTURE, i.e. it has the solution NF2_STRUCTURE = (([],[indf(s_name,t(1)),indf(s_code,t(2))]),t(seller1,2)). The rule relation_constructor(seller, [(([],[indf(s_name,t(1)),indf(s_code,t(2))]),t(seller1,2)),(([],[indf(s_name,t(1)),indf(s_code,t (2))]),t(seller2,3))],NF2_STRUCT) constructs one relation-valued attribute representation (an nf2-structure) from two nf2-structures of the same type. In other words it has the solution NF2_STRUCT = (([seller], [indf(seller,t(1)), indf(s_name,t(1,1)), indf(s_code,t(1,2))]), [t(seller1,2),t(seller2,3)]). It is possible to construct an NF2 relation by the construction rules concate_NF2 and relation_constructor by applying them recursively to atomic-valued attribute representations. By utilizing these rules we can also define flexibly other useful construction operations. For example, nf2_product(NF2_set1,NF2_set2,NF_set3) concatenates each nf2-structure in the set NF2_set1 to each nf2-structure in NF2_set2. The result is expressed in the argument NF2_set3. This rule is also defined in Appendix A and we apply it in our query processing. For example, nf2_product([(([],[indf(a,t(1))]),t(a1)),(([],[indf(a,t(1))]),t(a2))], [(([],[indf(b,t(1))]),t(b1)),(([],[indf(c,t(1))]),t(c1))],Res) gives the solution Res = [(([],[indf(a,t(1)),indf(b,t(2))]),t(a1,b1)), (([],[indf(a,t(1)),indf(c,t(2))]),t(a1,c1)), (([],[indf(a,t(1)),indf(b,t(2))]),t(a2,b1)), (([],[indf(a,t(1)),indf(c,t(2))]),t(a2,c1))]. The sample NF2 relation
10 First we introduce informally our sample NF2 relation and give its tabular visualization. After that we consider how it is represented as an nf2-structure constructed by the calculus. Our example is associated with a company which both sells products, which have been made from parts supplied by suppliers, and also sells these parts as such. Our sample environment consists of the following real world entities: • Products whose information content is defined by the attributes P-NAME, PRICE and MARKET. In terms of them the names, prices and market situations of products are expressed. At the instance level the values g, m and b of the attribute MARKET mean intuitively a good, moderate and bad market situation, respectively. • Sellers whose information content is defined by the attributes S-NAME and S-CODE. In terms of them the names and codes of sellers are expressed. In our sample environment there can be several sellers for each product and on the other hand each seller can sell several products. • Parts whose information content is defined by the attributes PA-NAME and PA-PRICE. In terms of them the names and prices of parts are expressed. Each product can be assembled from several parts and each part can be used in the construction of different products. • Part sellers whose information content is defined by the attributes PS-NAME and SWAY. In terms of them the names and ways of selling of part sellers are expressed. At the instance level the values p and s of the attribute S-WAY mean that a part seller sells a part primarily or secondarily, respectively. Each part seller can sell several parts and several part sellers can sell each part. In addition, it is possible that the same persons are both sellers of products and sellers of parts. • Suppliers whose information content is defined by the attributes SU-NAME, ADDR and S-TIME. In terms of them the names, addresses and supplying times of suppliers are expressed. Each supplier can supply several parts and each part can be supplied by several suppliers. Related to this sample environment we give in Fig.1 a tabular visualization for our sample NF2 relation which represents these real world entities as one complex object. In Fig.1 products, sellers, parts, part sellers and suppliers are expressed as the relation-valued attributes PRODUCT, SELLER, PART, PA-SELLER and SUPPLIER. PRODUCT P-NAME PRICE MARKET SELLER PART S-NAME S-CODE PA-NAME PA-PRICE PA-SELLER SUPPLIER PS-NAME S-WAY SU-NAME ADDR S-TIME -------------------------------------------------------------------------------------------------------------------------------------------p1
50
m
seller1 seller2
2 3
part1
15
seller1 p supp1 a1 seller3 s supp2 a2 seller4 s part4 20 seller1 s supp3 a3 seller2 p supp4 a4 -----------------------------------------------------------------------------------------------------------------------------------------p2 60 g seller3 4 part2 20 seller2 s supp5 a5 seller2 3 seller3 p supp2 a2 seller1 2 supp3 a3 part4 20 seller1 s supp3 a3 seller2 p supp4 a4 -----------------------------------------------------------------------------------------------------------------------------------------p3 80 b seller4 1 part4 20 seller1 s supp3 a3 seller3 4 seller2 p supp4 a4
2 3 1 2 3 4 2 1 2 1 2
11 seller2
3
part3
10
seller1 p supp5 a5 3 seller4 s supp2 a2 4 seller3 s part5 30 seller2 p supp4 a4 2 seller5 p ------------------------------------------------------------------------------------------------------------------------------------------
Figure 1. The tabular visualization of the sample NF2 relation The representation of the sample NF2 relation as an nf2-structure Our calculus is able to construct an NF2 relation from atomic-valued attribute representations, the smallest data units in the NF2 relational model. In order to demonstrate how our calculus constructs more complex nf2-structures from simpler ones we consider the construction of the nf2-structure which corresponds to the first row in the tabular representation of our sample NF2 relation. In Fig. 2 we give explicitly only those atomic-valued attribute representations which are necessary in our demonstration. For brevity, the application of the rule concate_NF2(NF2_STRUCT1,NF2_STRUCT2,NF2_STRUCT3) is denoted by NF2_STRUCT1 • NF2_STRUCT2 (i.e. it produces the NF2_STRUCT3) and the rule sequence concate_NF2(NF2_STRUCT1, NF2_STRUCT2, RES_NF2_STRUCT1), concate_NF2(RES_NF2_STRUCT1, NF2_STRUCT3, RES_NF2_STRUCT2) is denoted by NF2_STRUCT1 • NF2_STRUCT2 • NF2_STRUCT3 (i.e. the notation refers to the instantiated value of the argument RES_NF2_STRUCT2). The application of the rule relation_constructor(R,[NF2_STRUCT1, ... ,NF2_STRUCTn],RES) is denoted briefly by R [:] [NF2_STRUCT1, ... ,NF2_STRUCTn], i.e. it refers to the instantiated value of the argument RES. sun1 = (([],[indf(su_name, t(1))]),t(supp1)) sun2 = (([],[indf(su_name, t(1))]),t(supp2)) sun3 = (([],[indf(su_name, t(1))]),t(supp3)) sun4 = (([],[indf(su_name, t(1))]),t(supp4))
addr1 = (([],[indf(addr, t(1))]),t(a1)) addr2 = (([],[indf(addr, t(1))]),t(a2)) addr3 = (([],[indf(addr, t(1))]),t(a3)) addr4 = (([],[indf(addr, t(1))]),t(a4))
st1 = (([],[indf(s_time, t(1))]),t(1)) st2 = (([],[indf(s_time, t(1))]),t(2)) st3 = (([],[indf(s_time, t(1))]),t(3))
psn1 = (([],[indf(ps_name, t(1))]),t(seller1)) psn2 = (([],[indf(ps_name, t(1))]),t(seller2)) psn3 = (([],[indf(ps_name, t(1))]),t(seller3)) psn4 = (([],[indf(ps_name, t(1))]),t(seller4))
s_way1 = (([],[indf(s_way, t(1))]),t(p)) s_way2 = (([],[indf(s_way, t(1))]),t(s))
pa_price1 = (([],[indf(pa_price, t(1))]),t(15)) pa_price2 = (([],[indf(pa_price, t(1))]),t(20))
pa_name1 = (([],[indf(pa_name, t(1))]),t(part1)) s_code1 = (([],[indf(s_code, t(1))]),t(2)) pa_name2 = (([],[indf(pa_name, t(1))]),t(part4)) s_code2 = (([],[indf(s_code, t(1))]),t(3)) s_name1 = (([],[indf(s_name, t(1))]),t(seller1)) market1 = (([],[indf(market, t(1))]),t(m)) s_name2 = (([],[indf(s_name, t(1))]),t(seller2))
price1 = ((∅,[indf(price, t(1))]),t(50))
p_name1 = (([],[indf(p_name, t(1))]),t(p1))
Figure 2. The sample atomic-valued attribute representations
12 In order to abbreviate our text nf2-structures constructed by our concatenation operation are named with their own names as follows: su1 = sun1 • addr1 • st2. In other words, su1 means the nf2-structure ( ([],[indf(su_name,t(1)), indf(addr,t(2)), indf(s_time,t(3))]), t(supp1,a1,2)). In an analogous way we construct the following nf2-structures: su2 = sun2 • addr2 • st3, su3 = sun3 • addr3 • st1, su4 = sun4 • addr4 • st2, pa_seller1 = psn1 • s_way1, pa_seller2 = psn1 • s_way2, pa_seller3 = psn2 • s_way1, pa_seller4 = psn3 • s_way2, pa_seller5 = psn4 • s_way2, pa1 = pa_name1 • pa_price1, pa2 = pa_name2 • pa_price2, sel1 = s_name1 • s_code1, sel2 = s_name2 • s_code2, prod1 = p_name1 • price1 • market1. Because the nf2-structures su1 and su2 are of the same type we can apply our relation_constructor-rule to the set consisting of them. Thus, the notation supplier [:] [su1,su2] produces the nf2-structure (([supplier],[indf(supplier,t(1)), indf(su_name,t(1,1)), indf(addr,t(1,2)), indf(s_time,t(1,3))], [t(supp1,a1,2),t(supp2,a2,3)]). It is worth noting that the created nf2-structure represents structurally a relation of the relational model (the relation name is supplier and its attributes are su_name, addr and s_time). This shows also that the rule constructs in this case the instance as a set object consisting of structurally homogeneous tuples. Next we give the operation sequence which produces the object-based representation for the first row in the tabular visualization of our sample NF2 relation. It can be formed by the sequence: prod1 • (seller [:] [sel1,sel2]) • (part [:] [pa1 • (pa_seller [:] [pa_seller1,pa_seller4,pa_seller5]) • (supplier [:] [su1,su2]), pa2 • (pa_seller [:] [pa_seller2,pa_seller3]) • (supplier [:] [su3,su4]) ] ). We leave up to the reader to evaluate this sequence in detail. The result is the following nf2-structure: ( ([seller,part,pa_seller,supplier],[indf(p_name,t(1)), indf(price,t(2)), indf(market,t(3)), indf(seller,t(4)), indf(part,t(5)), indf(s_name,t(4,1)), indf(s_code,t(4,2)), indf(pa_name, t(5,1)), indf(pa_price,t(5,2)), indf(pa_seller,t(5,3)), indf(supplier,t(5,4)), indf(ps_name, t(5,3,1)), indf(s_way,t(5,3,2)), indf(su_name,t(5,4,1)), indf(addr,t(5,4,2)), indf(s_time, t(5,4,3))]), tree(p1,50,m,[t(seller1,2),t(seller2,3)],[tree(part1,15,[t(seller1,p),t(seller3,s),t(seller4,s)], [t(supp1,a1,2),t(supp2,a2,3)]),tree(part4,20,[t(seller1,s),t(seller2,p)],[t(supp3,a3,1),t(supp4, a4,2)]) ]) ). The object-based representations (some nf2-structures) for the second and third row in the tabular visualization of our sample NF2 relation are constructed in an analogous way. By applying the relation_constructor-rule (with the relation-valued attribute name product) to those object-based representations, which correspond to the rows in the tabular visualization of our sample NF2 relation, we achieve the object-based representation for
13 our sample NF2 relation in Fig. 3. We shall use this representation in our sample query evaluation. ( ([product,seller,part,pa_seller,supplier],[indf(product,t(1)), indf(p_name,t(1,1)), indf(price,t(1,2)), indf(market,t(1,3)), indf(seller,t(1,4)), indf(part,t(1,5)), indf(s_name,t(1,4,1)), indf(s_code,t(1,4,2)), indf(pa_name,t(1,5,1)), indf(pa_price,t(1,5,2)), indf(pa_seller,t(1,5,3)), indf(supplier,t(1,5,4)), indf(ps_name, t(1,5,3,1)), indf(s_way,t(1,5,3,2)), indf(su_name,t(1,5,4,1)), indf(addr,t(1,5,4,2)), indf(s_time,t(1,5,4,3))]), [ tree(p1,50,m,[t(seller1,2),t(seller2,3)],[tree(part1,15,[t(seller1,p),t(seller3,s),t(seller4,s)],[t(supp1,a1,2),t(supp 2,a2,3)]),tree(part4,20,[t(seller1,s),t(seller2,p)],[t(supp3,a3,1),t(supp4,a4,2)])]) , tree(p2,60,g,[t(seller3,4),t(seller2,3),t(seller1,2)],[tree(part2,20,[t(seller2,s),t(seller3,p)],[t(supp5,a5,3),t(supp 2,a2,4),t(supp3,a3,2)]),tree(part4,20,[t(seller1,s),t(seller2,p)],[t(supp3,a3,1),t(supp4,a4,2)])]) , tree(p3,80,b,[t(seller4,1),t(seller3,4),t(seller2,3)],[tree(part4,20,[t(seller1,s),t(seller2,p)],[t(supp3,a3,1),t(supp 4,a4,2)]),tree(part3,10,[t(seller1,p),t(seller4,s),t(seller3,s)],[t(supp5,a5,3),t(supp2,a2,4)]),tree(part5,30,[t(selle r2,p),t(seller5,p)],[t(supp4,a4,3)])]) ] ).
Figure 3. The object-based representation for the sample NF2 relation The properties of the object-based representation of an NF2 relation Next we list some useful properties related to the nf2-structure representation of an NF2 relation i.e. it is an anonymous tree object ((Rn,Indf),Instance): • The map object Indf is a bijective function. This is due to the construction rules of the calculus which on one hand accept only unique atomic-valued and relation-valued attribute names and on the other hand they associate a unique index with each attribute name and vice versa. This means that we can apply Indf uniquely in two ways: to find the attribute name associated with a given index and to find the index associated with a given attribute name. For example, if we denote the map object related to our sample NF2 relation by S_indf then the meta-rules maps(supplier,X,S_indf) and maps(Y,t(1,5,4),S_indf) have the solutions X = t(1,5,4) and Y = supplier, respectively. • The representation contains implicitly a mechanism in terms of which we can distinguish the atomic-valued attributes from the relation-valued attributes. In our representation only relation-valued attribute names are expressed explicitly by its own component Rn whereas atomic-valued attribute names are included implicitly in the map object Indf. By applying our meta-rules dom_range and set_intersection (see above) we define the atomic-valued attribute names as the following goal conjunction dom_range(Dom,Rng, Indf), set_intersection(Dom,Rn,A_names) where A_names expresses the atomic_valued attribute names. If this goal sequence is evaluated in the context of our sample NF2 relation then the argument A_names has the solution A_names = [p_name,price,market,s_name,s_code,pa_name,pa_price,ps_name,s_way,su_name,addr,s_t ime]. • The indices express the structurality among relation- and atomic-valued attributes. Our calculus forms the indices so that we can analyze both the substructures and superstructures related to a specific attribute in the nf2-structure at hand. Informally, the concepts 'superrelation' and 'subrelation' in an NF2 relation are defined as follows. If B is a
14 relation-valued attribute of a relation-valued attribute A then A is called a superrelation of B and B a subrelation of A. If B and A are related to each other so that no other relationvalued attributes are needed to connect them then A is called an immediate superrelation of B and B an immediate subrelation of A. Because in an NF2 relation many relationvalued attributes are nested it contains usually also indirect relationships among relationvalued attributes. If A is an immediate superrelation of B and in turn B is an immediate superrelation of C then A is an indirect superrelation of C and C an indirect subrelation of A. Super and subrelations in our representation can be analyzed very easily. Let t(1, ... ,X,Y) be an index related to any atomic-valued or relation-valued attribute. Then the index t(1, ... ,X) is the index of the relation-valued attribute in which the attribute appears immediately. If the index t(1, ... ,T,X,Y) is associated with a relation-valued attribute then the indices t(1, ... ,T,X), t(1, ... ,T), ... ,t(1) express the indices of its all superrelations. For example, in the context of our sample NF2 relation the index t(1,5,4) is associated with the relationvalued attribute supplier and thus the indices t(1,5), t(1) (related to the relation-valued attributes part and product, respectively) are the indices of its superrelations. Analogously to the definition of superrelations we can analyze the indices related to subrelations of a given relation-valued attribute. If the index t(1, ... ,D) is related to a relation-valued attribute then the index t(1, ... ,D,X) expresses an index of an atomicvalued or relation-valued attribute which is included immediately in this relation-valued attribute. If t(1, ... ,D) is the index related to a relation-valued attribute then the indices t(1, ... ,D,X), t(1, ... ,D,X,Y), t(1, ... ,D,X,Y,Z) and so on are indices of its subrelations provided that the solutions of the arguments R1,R2 and R3 in the meta-rules maps(R1,t(1, ... ,D,X),Indf), maps(R2,t(1, ... ,D,X,Y),Indf) and maps(R3,t(1, ... ,D,X,Y,Z),Indf) belong to the set Rn. For example, in our sample NF2 relation the index t(1,5) is related to the relation-valued attribute part and thus the indices t(1,5,3) and t(1,5,4) are associated with its subrelations (the relation-valued attributes pa-seller and supplier, respectively). In any NF2 relation there is a relation-valued attribute which has no superrelation. This relation is called the top relation. Typically we refer to the whole NF2 relation by its top relation name because all other attributes are either immediate or indirect components of the top relation. In our representation the index t(1) is associated with the top relation i.e. in our sample NF2 relation product is the top relation. In any NF2 relation there are relation-valued attributes which have no subrelations. In other words, they consist only of atomic-valued attributes. These relations are called bottom relations. The relation-valued attributes seller, pa_seller and supplier are the bottom relations in our sample NF2 relation. • The indexing mechanism binds the schema and instance levels together in a natural way. Let us consider as an example how we find values of the atomic-valued attribute s_code in our sample NF2 relation (see Fig. 3). The index function associates the index t(1,4,2) with s_code. We find the values from the instance by investigating its index components one after another in relevant substructures. The first component is 1 which means the whole instance. Next among its elements (the anonymous tree objects tree(p1, ...), tree(p2, ...), tree(p3, ....)) we are interested in their fourth component because of the number 4 in the index. Consider in more detail the fourth component in the tree object (p1, ...). We can refer to this component by the notation arg(4,tree(p1, ...),Comp) whose solution is Comp = [t(seller1,2),t(seller2,3)]. Finally among its elements we are interested in their second component because of the number 2 in the index. In other words the interesting components are: arg(2,t(seller1,2),Comp1) and arg(2,t(seller2,3),Comp2) the
15 solutions of which are Comp1 = 2 and Comp2 =3. This means that 2 and 3 are some values of the attribute s_code. Comparison with other logic-based representations proposed for NF2 relations The representation and manipulation of NF2 relations on the basis of the logic programming paradigm is, generally taken, very interesting. This is because it has been widely recognized that the database and logic programming areas are merging fast together. For example, many authors have realized that the relational model and Prolog has a common theoretical background. So far, numerous logic-based representations have been given for the relational databases whereas there are only a few representations for NF2 relational databases. In 46 it has been analyzed why it is very troublesome to represent and reconstruct NF2 relations on the basis of such logic programming languages which do not allow functions as arguments. For example, Datalog programs, although they consist of Horn clauses, do not allow function symbols as their arguments. The NESTED_DATALOG 47 and HILOGR 46 (in fact an extension of NESTED_DATALOG) logic languages have been developed especially for manipulating NF2 relations. These languages extend Datalog programs by allowing nested predicates without restricting nesting levels in any way. The NESTED_DATALOG and HILOG-R representations and our object-based representation for NF2 relations have the common feature that both the schema and instance levels are represented explicitly in them. However our representation and the NESTED_DATALOG and HILOG-R representations have some basic differences which we consider next. • Our representation for NF2 relations is processable in any standard Prolog environment whereas the NESTED_DATALOG or HILOG-R representations are not. • In our representation the schema is represented once whereas components belonging to the schema level in NESTED_DATALOG and HILOG-R are repeated for each occurrence of these components. Our representation separates the schema level clearly from the instance level and these levels are bound together via the indexing mechanism. The NESTED_DATALOG and HILOG-R representations do not contain this kind of a clear separation but in them components belonging to the instance and schema levels are mixed with each other. This also means that our representation offers a more compact way of representing NF2 relations, the instance level of which is large, than the corresponding NESTED_DATALOG or HILOG-R representations. This is because several replications of the same schema components are needed in a fact based on NESTED_DATALOG or HILOG-R. This in turn means that both less time for unification and less memory space are needed on the basis of our representation because our logical terms are shorter in these cases. Especially in main memory databases it is important that the data are represented a compact manner. • The development of a straightforward user interface for NF2 relational queries is possible only if the representation contains strong means to analyze structural relationships which prevail in an NF2 relation. As we have shown our representation supports the analysis of the structure of the NF2 relation. This is due to the fact that the schema is
16 represented as its own components and all structurality has been embedded into indices on the basis of which structural relationships can be analyzed in a straightforward way. The analysis based on the NESTED_DATALOG or HILOG-R representations, which do not contain separately manipulatable schema and instance levels, is much more cumbersome because the schema components appear among the instance components in large logical terms. The representation of stored NF2 relations Above we have considered how NF2 relations are represented as nf2-structures processable by our calculus. In query processing structural transformations among data are performed by utilizing the construction rules of our calculus, i.e. NF2 relations are represented then as nf2-structures. However in our prototype implementation we have two additional schema elements related to stored or source NF2 relations: the domain function related to atomicvalued attributes and the keys of the relation-valued attributes. The other components in the representation of source NF2 relation are same as in the nf2-structure representation. In our prototype implementation source NF2 relations are represented as a fact nf2((KeyIndices,Domf,Rn,Indf),Inst) where the components Domf and KeyIndices express the domain function and keys, respectively. The components Rn, Indf and Inst are represented exactly in the same way as in an nf2-structure representation. The construction of the corresponding nf2-structure representation from this representation happens simply by leaving out the components KeyIndices and Domf. The component Domf associates a domain with each atomic-valued attribute i.e. the values of an atomic-valued attribute belong to its domain. The component Domf is represented structurally as a map object. Because we concentrate here on query processing and in it there is no need to manipulate this component we do not consider the component in detail. The KeyIndices component contains the index of the key of each relation-valued attribute. The component KeyIndices is structurally a set object consisting of indices. Only in the case, that NF2 relations are in PNF (Partitioned Normal Form), it is meaningful to express the keys of the relation-valued attributes. An NF2 relation is said to be in PNF if a subset of its atomic-valued attributes on the uppermost level form its key and in addition each of its subrelations is in PNF. The formal definition of PNF is given e.g. in 48. Often, from the practical view point, NF2 relations in PNF form a meaningful subset of NF2 relations. Therefore many authors (e.g. 4,13,48-50) concentrate on dealing with NF2 relations with the PNF property. If the source NF2 relations are in PNF then we can use the keys, instead of all atomic-valued attributes of a relation-valued attribute, to preserve the semantic relationships among data. We also assumed in this paper that the source NF2 relations are in PNF. Our idea is to use minimal information in different phases of query processing and thus we can utilize the KeyIndices component to achieve this goal. It is worth noting that the KeyIndices component contains the keys of all relation-valued attributes in the source NF2 relation and the key of a relation-valued attribute can consist of one or more of its atomic-valued attributes. In the context of our sample NF2 relation (see Fig. 3) the atomic-valued attributes p_name, s_code pa_name, ps_name and su_name can be used as keys for the relation-valued attributes product, seller, part, pa_seller and supplier, respectively. Due to the analyzing power of our indexing mechanism we represent the keys of the relation-valued attributes as indices. This means that the
17 component KeyIndices of our sample NF2 relation is represented as the set object [t(1,1), t(1,4,2), t(1,5,1), t(1,5,3,1), t(1,5,4,1)] . In other words our sample NF2 relation is represented as the source relation representation nf2(([t(1,1),t(1,4,2),t(1,5,1),t(1,5,3,1),t(1,5,4,1)] ,_,Rn,Indf),Inst) where the components Rn, Indf and Inst are represented exactly in the same way as in Fig. 3. THE NF2RELATIONAL INTERFACE FROM THE USER VIEW POINT Above we have considered how NF2 relations are represented in terms of Prolog-based structural objects. Of course this implementation representation is invisible to the user. A user interface for NF2 relational queries has to be built so that the user can formulate her/his queries without knowing this representation. Two kinds of query languages have been developed for the NF2 relational model: formal languages and user-oriented languages. It is characteristic of different algebra-, calculus- or logic-based formal languages that their use requires skills which the end user usually does not possess whereas the idea of user-oriented languages is to offer a non-procedural highlevel tool for query formulation which is suitable to an ordinary end user. Generally taken the formal languages have been intended rather for the developers of database query languages than for the end users. In this paper we introduce both a user-oriented interface for NF2 relational queries and its logic-based or Prolog-based implementation. Our useroriented interface has to be such that the user can formulate queries by it without mastering logic-programming techniques. So far mainly various extensions of SQL (see e.g. 4-5,12-14) have been proposed for useroriented query languages based on the NF2 relational model. Because SQL (see e.g. 15) is able to manipulate only relations in first normal form (briefly 1NF relations) it has to be extended to manipulate NF2 relations. Typically this extension is defined so that wherever in SQL 1NF relations may occur now also NF2 relations are allowed. In addition, these languages contain expressions for data restructuring e.g. by using the reserved words NEST and UNNEST. The proposed SQL extension for NF2 relations are usually based on the traditional non-recursive algebra (see e.g. 51). It is typical of the definition of this algebra that its operations can only operate at the outermost nesting level. In SQL-like query formulation this means that if we have to manipulate in a query attributes, which do not reside at the outermost level, then we have to flatten (by applying UNNEST expressions) the relation until the attributes of interest are at the outermost level. Often after performing the operation (e.g. selection) on this flattened NF2 relation the result is restructured back into the structure of the original NF2 relation by NEST expressions. We have demonstrated in 52 that the user has to design and give large nested specifications in this kind of SQL formulation - even in such cases which do not presuppose restructuring among data. The idea of the recursive NF2 relational algebra (see e.g. 53) is to allow the manipulation of data on all nesting levels so that no restructuring is needed before accessing data on a specific nesting level. Colby 53 has demonstrated how queries can be formulated more compactly on the basis of a recursive algebra than a conventional non-recursive algebra. From our view point a SQL-like language based on a recursive algebra is a step towards a simpler user interface. However, also in this case large nested expressions are necessary if a query presupposes considerable restructuring among data.
18
From the view point of the user, more powerful tools are needed in order to facilitate complex restructuring among data in an NF2 relation. For example, in the Verso model 48 restructuring is performed by a general restructuring operator instead of nesting and unnesting operations. Also Hulin 50 has recognized that a more powerful operation is needed to perform total restructuring in an NF2 relation. He has developed this kind of a restructuring operation for NF2 relations in PNF which, in turn, is based on a flattening operation and its inverse operation. Our starting point is that the user should be able to formulate his/her queries at a very high abstraction level where (s)he does not need to express any restructuring operations explicitly. It has been widely recognized that the end user needs such a query language for manipulating NF2 relations which is easier to use than the SQL-like query languages extended for this purpose (see e.g. 5). In summary we can say that query formulation with an SQL extended for the NF2 relational model presupposes that the user masters the conventional SQL specification, the semantics of the restructuring operations and that (s)he is able to design large nested expressions in which restructuring expressions are embedded in conventional SQL expressions. In the context of complex NF2 relational queries the SQL-like query formulation resembles, from the user view point, rather the design of an algorithm than a non-procedural specification. Our NF2 relational interface minimizes the user effort in query formulation. From the end user viewpoint we state the following criteria for the NF2 relational interface: (A) Query formulation remains similar in the context of simple and complex queries. (B) Query formulation must be more compact on the basis of our interface than with an SQL-like query language. (C) The query interface has to allow general data restructuring. (D) Query formulation must be truly declarative. (F) The interface has to support the user's intuition to represent hierarchical relationships among the data in the result. The key idea in our NF2 relational interface is that the user specifies only the structure of the result of the query without specifying in any way how the result is derived from the source NF2 relation(s). This means a quite radical deviation from the existing approaches in which the user specifies the structural transformations. With respect to the existing NF2 relational query languages our approach can be characterized as an interface in which the query processing system deduces the needed restructuring operations on behalf of the user. In other words in our approach the user specifies the schema of the result and the query processing system is responsible for producing its instance from the source NF2 relation(s). There are several ways to define the structure of an NF2 relation, i.e. the hierarchy among atomic-valued and relation-valued attributes of the NF2 relation. Often it is represented as a set of rules (e.g. 13,48,54). However, ordinary end users are not accustomed to rule-based definitions. Therefore we seek for another alternative to represent the structure of an NF2 relation. We think that the concept 'linear form of the schema' (henceforth briefly form)
19 introduced by Schek and Scholl 55 is a natural, simple, but exact way to represent the structure of a NF2 relation. In our interface the structure of the result is represented as a form. In a form all atomic- and relation-valued attributes are represented explicitly and separated from each other by commas. Parentheses are used to describe hierarchical relationships among them. For example, R(A1,A2,R1(A3,A4,A5,R2(A6,A7)),R3(A8,A9)) is a form where R1, R2, R3 and A1, A2, ... , A9 are relation-valued and atomic-valued attribute names in the NF2 relation R, respectively. In fact we can think that the whole NF2 relation consists of one relation-valued attribute R, i.e. the outermost relation-valued attribute (top relation) name in a form can be used to refer to the whole NF2 relation. Our sample NF2 relation product has the form: product(p_name,price,market,seller(s_name,s_code), part(pa_name,pa_price,pa_seller(ps_name,s_way), supplier(su_name,addr,s_time))). In our approach any query is expressed by the logical term nf2_query(Relname, Q_pred, Form) where • Relname expresses the name of the source NF2 relation (later on we shall consider queries which are able to manipulate several source NF2 relations). • Q_pred or the query predicate contains those conditions specified by the user which data selected to the result have to satisfy. • Form expresses the form or the structure of the result NF2 relation of the query. If the user does not want to give any query predicate in his/her query then the second argument in the term is the atom 'true'. In the Appendix B we give the BNF notation which defines our interface exactly. It is worth noting that the query predicate is defined so that it allows the user to express really complex conditions in his/her queries. This is very important from the view point of the expressive power of the interface. Elementary predicates comparing two atomic-valued attributes are expressed by the Prolog functor epa whereas elementary predicates comparing an atomic-valued attribute and a value are expressed by the Prolog functor epv. Several conventional comparison operators can be used in them. We believe that other elementary predicates are self-explanatory. More complex conditions are constructed from elementary predicates by logical connectives. It is assumed in our interface that all atomic-valued attribute names in a form appear also in the source NF2 relation(s) whereas the relation-valued attribute names can differ from those in the source NF2 relation(s). This is necessary because, on one hand, the result NF2 relation has to be derived from the values of atomic-valued attributes in the source NF2 relation(s) and, on the other hand, the result NF2 relation can contain relation-valued attributes whose atomic-valued attributes belong to different relation-valued attributes in the source NF2 relation(s). Next we introduce the sample query formulated by our interface whose evaluation will be followed through the paper. Let us assume that the user is interested in those products related to our sample environment which are sold by the seller with the code 1. For each such product (s)he wants to know the names and addresses of those suppliers which supply a part which is needed in the construction of the product at hand. In order to make a query on the basis of our interface the user has to specify the name of the source NF2 relation ( in this case product), the query predicate epv(s_code,=,1) and the form which can be expressed e.g. as the term needed_suppliers(p_name, suppliers(su_name, addr)) which is
20 structurally a named tree object. In other words the whole query, called Sample Query 1, can be expressed as follows: Sample Query 1: nf2_query(product,epv(s_code,=,1),needed_suppliers(p_name, suppliers(su_name, addr)),Result) The result of Sample Query 1 is visualized in Fig. 4. This tabular visualization corresponds to the nf2-structure representation of the argument Result which is produced by our query processing system. How our query processing system produces this result will be considered in detail.
needed_suppliers p_name
p3
suppliers su_name supp3 supp5 supp2 supp4
addr a3 a5 a2 a4
Figure 4. The tabular visualization of the result of the Sample Query 1 The Sample Query 1 represents a quite complex query because in our sample NF2 relation the product and supplier data depend on each other indirectly via the part data and in the result they depend immediately, i.e. data restructuring is needed. In addition the condition in the query concerns data which are not included in the result. In fact the data in the condition do not belong to the same hierarchical path in the source NF2 relation as the data collected to the result. In order to assure the reader of that our interface satisfies the objectives ((A)-(F)) stated above we give two sample queries more. Let us assume that the user is interested in those suppliers, which supply cheap parts to the company, and those products, which contain these parts. We consider that a part is cheap if its price • 15. For each such supplier the user wants to get all those products which contain at least one cheap part supplied by the supplier. The user wants to know the names (the attribute su_name) and addresses (the attribute addr) of the suppliers and the names (the attribute p_name) and prices (the attribute price) of the products. In our interface the user has to specify: • the name of the source NF2 relation (product), • the condition (pa_price,•,'15') • the form of the query, e.g. as follows cheap_part_supplier(su_name,addr, prod(p_name, price)) where cheap_part_supplier and prod are relation-valued attribute names given by the user. Now the whole query from the user view point is represented as follows. Sample Query 2: nf2_query_evaluator(nf2_query(product, epv(pa_price, •, 15), cheap_part_supplier(su_name, addr, prod(p_name, price))), Result) In Fig.5 we give the result of the evaluation of this query as a tabular visualization. This sample query shows clearly that also queries, which require drastic restructuring, can be formulated in a compact manner. Producing the result means that hierarchical relationships
21 have to be inverted among those data which depend indirectly on each other in the source NF2 relation. Also, in this query the condition concerns the attribute which is not included in the form. cheap_part_supplier su_name supp1 supp5 supp2
addr a1 a5 a2
prod p_name p1 p3 p1 p3
price 50 80 50 80
Figure 5. The tabular visualization of the result of the Sample Query 2 Assume the user is interested in those part sellers which sell secondarily such a part supplied by the suppliers supp1 or supp3 or supp5 whose price is less than 20. If the user wants the result to have the form salesman_of_parts(ps_name, s_way) then the query can be expressed as Sample Query3. Sample Query 3: nf2_query_evaluator(nf2_query(product, epv(pa_price, COMP_VALUE,!, max_base(L,MAX_BASE,BASE). max_base([indf(ATTR_NAME,INDEX)|L],MAX_BASE,COMP_VALUE):max_base(L,MAX_BASE,COMP_VALUE). max_base([],MAX_BASE,MAX_BASE). /* The predicate cat_index_transf(INDF,MAX_BASE,MODIF_INDF) transforms the index function INDF so that the positive integer MAX_BASE is added to the first
41 component of each index in INDF. The index function modified in this way is expressed by the argument MODIF_INDF. */ cat_index_transf([indf(ATTR_NAME,INDEX1)|L1],MAX_BASE,[indf(ATTR_NAME,I NDEX2)|L2]):INDEX1=..[t|[FIRST|REST]],MODIFIED is FIRST+MAX_BASE, INDEX2 =..[t|[MODIFIED|REST]], cat_index_transf(L1,MAX_BASE,L2). cat_index_transf([],MAX_BASE,[]). Definition of the construction rule relation_constructor
relation_constructor(NF2_REL_NAME,[((RN,INDF),INST)|REST], ((R_RN,R_INDF),R_INST)):/* The construction of the schema level */ set_union([NF2_REL_NAME],RN,R_RN), rel_index_transformation(INDF,INDF1), /* The index function INDF1 is constructed from INDF so that the number 1 is placed to the first component in its indices. Other components in the indices of INDF1 are as in INDF. */ append([indf(NF2_REL_NAME,t(1))],INDF1,R_INDF), /*The index t(1) is associated with NF2_REL_NAME */ rel_instance_construction(REST,CONSTR_REST), /* This predicate constructs the instance level from the instances of nf2-structures in REST*/ append([INST],CONSTR_REST,R_INST). rel_instance_construction([(SCHEMA,INSTANCE)|REST1],[INSTANCE|REST2]):rel_instance_construction(REST1,REST2). rel_instance_construction([],[]). rel_index_transformation([indf(COMP_NAME,INDEX1)|REST1], [indf(COMP_NAME,INDEX2)|REST2]):INDEX1=..[t|INDICES], INDEX2=..[t|[1|INDICES]], rel_index_transformation(REST1,REST2). rel_index_transformation([],[]). Definition of the construction rule nf2_product
/* nf2_product(NF2_set1,NF2_set2,NF2_set3) concatenates each nf2-structure in NF2_set1 to each nf2-structure in NF2_set2. The result is expressed by NF2_set3 (a set object). */ nf2_product(NF2_set,[],NF2_set):-!. nf2_product([],NF2_set,NF2_set):-!. nf2_product(NF2_set1,NF2_set2,NF2_set3):findall(X,combine(NF2_set1,NF2_set2,X),NF2_set3)./* findall is a predicate which is available in a standard Prolog environment (its definition is e.g. in 18,45) */ combine(NF2_set1,NF2_set2,AB):member(A,NF2_set1),member(B,NF2_set2),concate_NF2(A,B,AB).
42 APPENDIX B Definition of the NF2relational query interface
→ nf2_query(,, ) → ({,}*) → | → → → → {or }* → {neg}o {and }* → | () → | → | | | → epv(, , ) → epa(, , ) → true | false → one_of(, ) → between(, ) → < | •| = | •| > | • → [ {, }*] → [, ] → → |
43
A PPEN D IX C
44 trans_to_inter(NF2-STRUCT: product(p_name,price,market,seller(...),part(...)), PROJ_IND: (I(p_name),I(s_code),I(pa_name),I(su_name),I(addr))) /* CASE A */ trans_to_inter(NF2-STRUCT: p_name,price,market,seller(...),part(...), PROJ_IND: (I(p_name),I(s_code),I(pa_name),I(su_name),I(addr))) /* CASE B */ CONSTRUCT p_name
trans_to_inter(NF2-STRUCT: seller(...),part(...), PROJ_IND: (I(s_code),I(pa_name),I(su_name),I(addr))) /* CASE A */
trans_to_inter(NF2-STRUCT: seller(...), PROJ_IND: (I(s_code)))
trans_to_inter(NF2-STRUCT: part(...), PROJ_IND: (I(pa_name),I(su_name),I(addr)))
/* CASE A */
/* CASE A */
trans_to_inter(NF2-STRUCT: s_name,s_code, PROJ_IND: (I(s_code)))
trans_to_inter(NF2-STRUCT: pa_name, pa_price,pa_seller(...),supplier(...), PROJ_IND:(I(pa_name),I(su_name),I(addr)))
/* CASE B */ /* CASE B* / CONSTRUCT s_code
CONSTRUCT pa_name
trans_to_inter( NF2-STRUCT: pa_seller(...),supplier(...), PROJ_IND:(I(su_name),I(addr))) /* CASE A */ trans_to_inter(NF2-STRUCT: supplier(su_name,addr), PROJ_IND:(I(su_name),I(addr))) /* CASE A */ trans_to_inter(NF2-STRUCT: su_name,addr, PROJ_IND:(I(su_name),I(addr))) /* CASE B */ CONSTRUCT su_name,addr
trans_to_inter(NF2-STRUCT: PROJ_IND:()) /* CASE C */ []
nf2-product( , ) su_name,addr nf2-product( , ) pa_name,su_name,addr nf2-product( , ) s_code,pa_name,su_name,addr nf2-product( , ) p_name,s_code,pa_name,su_name,addr
45 A PPEN D IX D nf2_result_construct(I-mediate: I1, T-Form: needed_suppliers(p_name,suppliers(su_name,addr))) CASE I needed_suppliers
nf2_result_construct(I-mediate: I1,
CASE II [(([],[indf(p_name, t(1))]),t(p3))]
nf2_result_construct(I-mediate: I1, T-Form: suppliers(su_name,addr)) CASE I
suppliers
nf2_result_construct(I-mediate: I2, T-Form: su_name,addr) CASE II [(([],[indf(su_name, t(1)), indf(addr, t(2))]),t(supp3,a3)), (([],[indf(su_name, t(1)), indf(addr, t(2))]),t(supp5, a5)), (([],[indf(su_name, t(1)), indf(addr, t(2))]),t(supp2, a2)), (([],[indf(su_name, t(1)), indf(addr, t(2))]),t(supp4, a4))]
relation_constructor( , )
(([suppliers], [indf(suppliers, t(1)), indf(su_name, t(1, 1)), indf(addr, t(1, 2))]), [t(supp3, a3), t(supp5, a5), t(supp2, a2), t(supp4, a4)]))
nf2_set_join( ,
)
[(([suppliers], [indf(p_name, t(1)), indf(suppliers, t(2)), indf(su_name, t(2, 1)), indf(addr, t(2,2))]), tree(p3, [t(supp3, a3), t(supp5, a5), t(supp2, a2), t(supp4, a4)]))]
relation_constructor( , )
([needed_suppliers, suppliers], [indf(needed_suppliers, t(1)), indf(p_name, t(1, 1)), indf(suppliers, t(1, 2)), indf(su_name, t(1, 2, 1)), indf(addr, t(1, 2, 2))]), [tree(p3, [t(supp3, a3), t(supp5, a5), t(supp2, a2), t(supp4, a4)])]
/* In the predicate nf2_query_evaluator the first argument is a query specified by the user and it is represented as the term nf2_query(NF2_RelName,Conditions,Form). In the case
46 that the user does not want to specify any condition the argument Conditions is replaced by the atom true.*/ nf2_query_evaluator(nf2_query(NF2_RelName,Conditions,Form),Result):make_schema_components(Form,q_schema(RN,Indf)), /* The above predicate represents the form of a query as an object-based way identical with an NF2 relational schema. */ dom_range(Indf,Comps,_), set_difference(Comps,RN,Attrs1), /* The attribute Attrs1 contains all those atomic-valued attribute names which are included in the form specified by the user. */ predicate_attributes(Conditions, Attrs2), /* This predicate analyzes the condition expression (the argument Conditions) given by the user and constructs the set Attrs2 consisting of all atomic-valued attributes in the condition expression. */ set_union(Attrs1,Attrs2,Attrs), /* The argument Attrs expresses all atomic-valued attribute names specified by the user in his/her query. */ search_nf2(NF2_RelName,nf2((KeyIndices,Domf,RelNames,Source_Indf),Instance)), /* This predicate searches the complete object-based representation for the NF2 relation at hand */ corresponding_indices(Source_Indf,Attrs,Index_Set1), /* The argument Index_Set1 expresses the indices of interest atomic-valued attributes in the source NF2 relation. */ all_necessary_keys(KeyIndices,Index_Set1,SelectedKeyIndices), /* The argument SelectedKeyIndices expresses all necessary keys which have to manipulate in query processing in order to preserve semantic relationships among data. */ set_union(SelectedKeyIndices,Index_Set1,Indices_for_Intermediate), /* The argument Indices_for_Intermediate contains the indices of those atomic-valued attributes whose values are included in the intermediate representation.*/ write(' The indices of those atomic-valued attributes of the source relation whose values have to be collected into the intermediate form'), nl,write(Indices_for_Intermediate),nl, /* The end of the phase I*/ write(' The intermediate representation of the query at hand '),nl,nl, project_and_normalize(((RelNames,Source_Indf),tree(Instance)),Indices_for_Intermediate, Intermediate),/* The predicate project_and_normalize presupposes that the instance level is structurally of type tree. Therefore the expression tree(Instance) is necessary because it transforms a set object to a tree object*/ write(Intermediate),nl,nl, nf2_selection(Intermediate, Conditions, S_Intermediate), /* This predicate selects the subset of the intermediate representation which satisfies the condition expression specified by the user (the argument Conditions) */ write(' The intermediate representation after the condition evaluation '),nl,nl,write(S_Intermediate), nl, nl, nl, nf2_result_construction(S_Intermediate,q_form(RN,Indf),Result). /* The predicate constructs the result NF2 relation organized according to the schema represented in the term q_form(RN,Indf).*/ make_schema_components(Form,q_schema(RN,Indf)):handle_nf2_relation(Form,[1],RN,Indf). /* The second argument (in this case [1]) expresses a base that appears in the beginning of all indices of those attributes which are components of the relation-valued attribute Form.*/
47 handle_nf2_relation(Form,Base,RN,Indf):functor(Form,Functor,N), /* The argument Functor expresses a relation-valued attribute name*/ Form=..[Functor|Comp_list], traverse_level(Comp_list,Base,1,RN1,Indf1), /* This predicate constructs both the relation-valued attribute names (the argument RN1) and the index function (the argument Indf1) from the components of Form. This construction starts from its first component. The component being considered is expressed by the third argument.*/ append([Functor],RN1,RN), Index=..[t|Base], append([indf(Functor,Index)],Indf1,Indf). traverse_level([Comp|Rest],Base,Position,RN,Indf):-atomic(Comp),!, /* The component being considered is an atomic-valued attribute name. */ Position1 is Position+1, traverse_level(Rest,Base,Position1,RN,Indf1), append(Base,[Position],L),Index=..[t|L],append([indf(Comp,Index)],Indf1,Indf). traverse_level([Comp|Rest],Base,Position,RN,Indf):/* The component being considered is a relation-valued attribute name. */ Position1 is Position+1, traverse_level(Rest,Base,Position1,RN1,Indf1), append(Base,[Position],NewBase), handle_nf2_relation(Comp,NewBase,RN2,Indf2), append(RN2,RN1,RN), append(Indf2,Indf1,Indf). traverse_level([],Base,Position,[],[]). search_nf2(NF2_RelName,nf2((KeyIndices,Domf,RelNames,Source_Indf),Instance)):nf2((KeyIndices,Domf,RelNames,Source_Indf),Instance), on(indf(NF2_RelName,t(1)),Source_Indf)/* an nf2-fact has to satisfy the condition that NF2_RelName appears as its outermost relation-valued attribute name*/. /* The predicate corresponding_indices(Source_Indf,Attribute_Set,Index_Set) replaces the set of the attribute names (the argument Attribute_Set) by their indices (the argument Index_Set) in the nf2-struture at hand. Thus this predicate can also be applied in the context of a source NF2 relation. */ corresponding_indices(Source_Indf,[Attr|Rest1],[Index|Rest2]):maps(Attr,Index,Source_Indf),/* We can apply the meta-rule maps because Source_Indf is a map object.*/ corresponding_indices(Source_Indf,Rest1,Rest2). corresponding_indices(Source_Indf,[],[]). /* The predicate all_necessary_keys(KeyIndices,Index_Set,SelectedKeyIndices) defines those keys (the argument SelectedKeyIndices) whose manipulation is necessary in order to preserve semantic relationships among data. The argument Index_Set expresses the indices of those atomic-valued attributes which the user has specified in his/her query. The argument KeyIndices is a set consisting of keys of the relation-valued attributes of the source NF2-relation*/
48
all_necessary_keys(KeyIndices,Index_Set,SelectedKeyIndices):find_out_relation_indices(Index_Set,Relation_Indices1), /* This predicate gives the indices of those relation-valued attributes whose intermediate atomic-valued appear in the query at hand i.e. in the argument Index_Set*/ remove_duplicates(Relation_Indices1,Relation_Indices), /* The predicate removes duplicate occurrences of indices*/ define_superkeys(Relation_Indices,KeyIndices,SelectedKeyIndices) /* This predicate defines the indices of all intermediate and indirect superrelations of those relation-valued attributes whose indices are in the set Relation_Indices*/. find_out_relation_indices([Index1|Rest1],[Index2|Rest2]):Index1=..[t|Indices1], append(Indices2,[A],Indices1), Index2=..[t|Indices2], /* Index2 is constructed from Index1 by removing its last number. */ find_out_relation_indices(Rest1,Rest2). find_out_relation_indices([],[]). define_superkeys([Relation_Index|Rest],KeyIndices,SelectedKeyIndices):keys_in_super_relations(Relation_Index,KeyIndices,Key_to_Relation),define_superkeys( Rest,KeyIndices,SelectedKeyIndices1), set_union(Key_to_Relation,SelectedKeyIndices1,SelectedKeyIndices). define_superkeys([],KeyIndices,[]). /*keys_in_super_relations(Relation_Index,Key_Indices,Key_to_Relation)*/ keys_in_super_relations(t(X),Key_Indices,Key_to_Relation):!,findall(Key_Component,key_component(t(X),Key_Indices,Key_Component),Key_to_Re lation). keys_in_super_relations(Relation_Index,Key_Indices,Key_to_Relation):findall(Key_Component,key_component(Relation_Index,Key_Indices,Key_Component), Relation_Key), Relation_Index=..[t|Indices], append(Indices1,[A],Indices), New_Relation_Index=..[t|Indices1], keys_in_super_relations(New_Relation_Index,Key_Indices,Key_to_Relation1), append(Key_to_Relation1,Relation_Key,Key_to_Relation). key_component(Relation_Index,Key_Indices,Key_Component):on(Key_Component,Key_Indices), Key_Component=..[t|Indices1], Relation_Index=..[t|Indices2], append(Indices2,[A],Indices1).
49
Referen ssit,joista poim itaan [1] [2] [3] [4] [5] [6] [7] [8] [9]
[10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
H. Abramson, and V. Dahl, Logic Grammars. Berlin : Springer-Verlag, 1989. R. Agrawal, "Alpha: An Extension of Relational Algebra to Express a Class of Recursive Queries," Proc. 3rd IEEE Data Engineering Conf., Los Angeles, 1987, pp. 580-590, 1987. T. Amble, Logic Programming and Knowledge Engineering. Wokingham : Addison-Wesley, 1987. M.M. Astrahan, and D.D. Chamberlin, "Implementation of a Structured English Query Language," Communications of the ACM, vol. 18, no. 10, pp. 580-588, 1975. F. Bancilhon, and S. Khoshafian, "A Calculus for Complex Objects," Proc. 5th ACM SIGMOD-SIGACT Symposium on Principles of Database Systems, Massachusetts, 1986. New York, NY : ACM, pp. 53-59, 1986. F. Bancilhon, T. Briggs, S. Khoshafian, and P. Valduriez, "FAD, a Powerful and Simple Database Language," Proc. 13th VLDB Conf., Brighton, 1987, pp. 97-105, 1987. D. Bitton, "The Effect of Large Main Memory on Database Systems," Proc. ACM SIGMOD Conf., Washington, 1986. New York, NY : ACM, pp. 337-339, 1986. D. Bjorner, "Programming in the Meta-Language," The Vienna Development Method. Berlin : Springer - Verlag, pp. 24 - 217, 1978. C. Beeri, S. Naqvi, R. Ramakrishnan, O. Shmueli, and S. Tsur, "Sets and Negation in Logic Database Language (LDL1)," Proc. 6th ACM SIGMODSIGACT Symposium on Principles of Database Systems, San Diego, 1987. New York, NY : ACM, pp. 21-37, 1987. I. Bratko, PROLOG: Programming for Artificial Intelligence. Reading, MA : Addison-Wesley, 1986. M. L. Brodie, "Research Issues in Database Specification," ACM SIGMOD Record, vol. 13, no. 3, pp. 42 - 45, 1983. S. Ceri, and G. Gottlob, "Normalization of the Relations and Prolog," Communications of the ACM, vol. 29, no. 6, pp. 524-544, 1986. S. Ceri , G. Gottlob, and L. Tanca, Logic Programming and Databases. Berlin : Springer-Verlag, 1990. A. Y. Chan, Index Selection in a Self-Adaptive Relational Data Base Management System. Cambridge, MA: MIT, Lab. for Computer Science, Report MIT/LCS/TR-166, 1976. C.L. Chang, "On Evaluation of Queries Containing Derived Relations in a Relational Data Base," in Advances in Data Base Theory, vol. 1. Plenum Publishing Corp., pp. 235 - 260, 1981. S. Christodoulakis, "Estimating Record Selectivities," Information Systems, vol. 8 no. 2, pp. 105-115, 1983. C.L. Chang, and A. Walker, "PROSQL: A Prolog Programming Interface with SQL/DS," Proc. The First International Workshop on Expert Database Systems. Menlo Park, CA: Benjamin/Cummings Publishing Company, pp. 233 - 246, 1986. E. Clemons, "Design of an External Schema Facility to Define and Process Recursive Structures," ACM TODS, vol.6, no.2, pp. 295-311, 1981. W. Clocksin, and C. Mellish, Programming in Prolog. Berlin : Springer-Verlag, 1981. E. F. Codd, The Relational Model for Database Management : Version 2. Reading, MA : Addison-Wesley, 1990.
50 [21] V. Dahl, "On Database Systems Development Through Logic," ACM TODS, vol. 17, no. 1, pp. 102-123, 1982. [22] D. Delobel, "An Overview of the Relational Data Theory," Proc. IFIP 80. Amsterdam : North - Holland, pp. 413 - 426, 1980. [23] D. J. DeWitt et al., "Implementation Techniques for Main Memory Databases," Proc. ACM SIGMOD, Boston, June 18 - 21, 1984. New York, NY: ACM, pp. 1 8, 1984. [24] P. M. D. Gray, "Efficient Prolog Access to Codasyl and FDM Databases," Proc. ACM SIGMOD Conf., Texas, May 28-31, 1985. New York, NY: ACM, pp. 437443, 1985. [25] A. Guttman, New Features for Relational Database Systems to Support CAD Applications. Berkley, CA : Univ. of California, Computer Science Dept., Ph.D. Dissertation, June 1984. [26] D. I. Howells, N. J. Fiddian, and W. A. Gray, "A Source - to - Source MetaTranslation System for Relational Query Languages," Proc. 13th VLDB Conf., Brighton, 1987, pp. 227-234, 1987. [27] H. V. Jagadish, and R. Agrawal, "A Study of Transitive Closure as a Recursion Mechanism," Proc. ACM SIGMOD Conf., San Francisco, 1987. New York, NY : ACM, pp. 331-334, 1987. [28] K. Järvelin, and T. Niemi, Entity-Based Query Construction for Relational Database Access. Tampere, Finland: University of Tampere, Dept. of Computer Science, Report A-1990-6, 1990. [29] K. Järvelin, "Boolean Predicate Reduction for File Access," In : H. Kangassalo and S. Ohsuga and H. Jaakola (Eds.), Information Modelling and Knowledge Bases. Amsterdam : IOS Press, pp. 388-406, 1990. [30] C. Kellog, A. O'Hare, and L. Travis, "Optimizing the Rule - Data Interface in a KMS," Proc. 12th VLDB Conf., Kyoto, 1986, pp. 42-51, 1986. [31] S. Kunifuji, and H. Yokota, "Prolog and Relational Data Bases for Fifth Generation Computer Systems," Proc. Workshop On Logical Bases for Data Bases. Tolouse, 1982. [32] Y. Y. Leung, and D. L. Lee, "Logic Approaches for Deductive Databases," IEEE Expert, Winter Issue, pp. 64-75, 1988. [33] D. Li, A PROLOG Database System. Letchworth : Research Studies Press, 1984. [34] R. Lucas, Database Applications Using Prolog. Chichester : Ellis Horwood, 1988. [35] D. Maier, The Theory of Relational Databases. London : Pitman, 1984. [36] M. McCord, "Natural Language Processing in Prolog," in Knowledge Systems and Prolog. Reading, MA : Addison-Wesley, pp. 437-453, 1987. [37] M. Missikoff, and G. Wiederhold, "Towards a Unified Approach for Expert and Database Systems," Proc. The First International Workshop on Expert Database Systems. Menlo Park, CA: Benjamin/Cummings Publishing Company, pp. 383 399, 1986. [38] S. P. Navathe, and J. B. Fry, "Restructuring for Large Databases: Three Levels of Abstraction," ACM TODS, vol. 1, no. 2, pp. 138 - 158 (1976). [39] P. Naur, "Formalization in Program Development," BIT, vol. 22, no. 4, pp. 437 453, 1982. [40] T. Niemi, "Formal Restructuring Functions for Hierarchical Data Bases," Internat. J. of Computer and Information Sciences, vol. 12, no. 6, pp. 385 - 411, 1983. [41] T. Niemi, "Specification of a Query Language by the Attribute Method," BIT, vol. 24, pp. 171 - 186, 1984. [42] T. Niemi, and K. Järvelin, "A Straightforward Formalization of the Relational Model," Information Systems, vol. 10, no. 1, pp. 65 - 76, 1985.
51 [43] T. Niemi, and K. Järvelin, A Meta-Information Approach to Relational Database Representation and Manipulation Based on Prolog. Tampere, Finland : University of Tampere, Dept. of Computer Science, Report A-1988-11, 1988. [44] T. Niemi and K. Järvelin, Operation-Oriented Query Language Approach for Recursive Queries. Tampere, Finland : University of Tampere, Dept. of Computer Science, Report A-1990-2, 1990. [45] T. Niemi, and K. Järvelin, The Rule-Based Prototype Implementation for the Operation-Oriented Recursive Query Language Approach and its Integration with Relational Databases. Tampere, Finland : University of Tampere, Dept. of Computer Science, Report A-1990-9, 1990. [46] T. Niemi, and K. Järvelin, "Deductive Database Queries Based on Transitive Relationships and Entity Types," Information Processing & Management, to appear, 1991. [47] Z. Ozsoyogly, and L. Yuan, "A Normal Form for Nested Relations," Proc. 4th Symposium on Principles of Database Systems. New York, NY: ACM, pp. 251 260, 1985. [48] F. C. N. Pereira, and D. H. D. Warren, "Definite Clause Grammars for Language Analysis - A Survey of the Formalism and a Comparison with Augmented Transition Networks," Artificial Intelligence, vol. 13, pp. 231-278, 1980. [49] A. Pirotte, "A Precise Definition of Basic Relational Notations and of the Relational Algebra," ACM SIGMOD Record, vol. 13, no. 1, pp. 30 - 45, 1982. [50] A. Rosenthal, S. Heiler, U. Dayal, and F. Manola, "Traversal Recursion: A Practical Approach to Supporting Recursive Applications," Proc. ACM SIGMOD Conf., Washington, 1986. New York, NY : ACM, pp. 166-176, 1986. [51] M. A. Roth, "The Design of ¬1NF Relational Databases into Nested Normal Form," Proc. ACM SIGMOD Conf., San Fransisco, May 27 - 29, 1987. New York, NY : ACM, pp. 143 - 159, 1987. [52] M. Schkolnick, and P. Tiberio, A Note on Estimating tha Maintenance Cost in a Relational Database. San Jose, CA: IBM Reasearch Laboratory, Rep. RJ 3327 (40084), 1981. [53] E. Sciore, Database Facilities for Prolog. Stony Brook, NY: State Univ. of New York, Dept. of Computer Science, Tech. Rep. 85/012, 1985. [54] E. Sciore, and D. S. Warren, "Towards an Integrated Database-Prolog System," Proc. The First International Workshop on Expert Database Systems. Menlo Park, CA: Benjamin / Cummings Publishing Company. pp. 293 - 305, 1986. [55] P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A. Lorie, R. A., and T. G. Price, "Access Path Selection in a Relational Database Management System," Proc. ACM SIGMOD Conference, Boston, MA, May 30 - June 1, 1979. New York, NY : ACM, pp. 23-34, 1979. [56] B. Shneiderman, and Thomas G., "An Architecture for Automatic Relational Database System Conversion," ACM TODS, vol. 7, no. 2, pp. 235 - 257, 1982. [57] J. M. Smith, and P. Y.-T. Chang, "Optimizing the Performance of a Relational Algebra Database Interface," Communications of the ACM, vol. 18 no. 10, pp. 568-579, 1975. [58] L. Sterling, and E. Shapiro, The Art of Prolog. Cambridge, MA : The MIT Press, 1986. [59] T. J. Teorey, and J. R. Fry, Design of Database Structures. Englewood Cliffs, NJ: Prentice-Hall, 1982. [60] S. Tsur, and C. Zaniolo, "LDL: A Logic-based Data-language," Proc. 12th VLDB Conf., California, pp. 33-41, 1986. [61] J. D. Ullman, Principles of Data Base Systems. Rockville, MD : Computer Science Press, 1980.
52 [62] J. D. Ullman, "Implementation of Logical Query Languages for Databases," ACM TODS, vol. 10, no. 3, pp. 289-321, 1985. [63] J. D. Ullman, Principles of Database and Knowledge Base Systems. Vol. I. Rockville, MD : Computer Science Press, 1988. [64] J. D. Ullman, Principles of Database and Knowledge Base Systems. Vol. II : The new technologies. Rockville, MD : Computer Science Press, 1989. [65] H. Yokota, S. Kunifuji, T. Kakuta, N. Miyazaki, S. Shibayama, and K. Murakami, "An Enhanced Inference Mechanism for generating Relational Algebra Queries," Proc. 3rd Symposium on Principles of Database Systems. New York, NY : ACM, pp. 229 - 238, 1984. [66] T. Yokomori, "A Logic Program Schema and its Applications," Proc. 9th International Joint Conference on Artificial Intelligence, Los Angeles. Los Altos, CA : Morgan Kaufmann, pp. 723-725, 1985. [67] C. T. Yu, and Y. C. Lin, "Some Estimation Problems in Distributed Query Processing," Proc. IEEE Distributed Computing Systems Conference, pp. 13-19, 1982. [68] C. Zaniolo, "Prolog: A Database Query Language for all Seasons," Proc. The First International Workshop on Expert Database Systems. Menlo Park, CA: Benjamin / Cummings Publishing Company, pp. 219 - 232, 1986. [69] H. Zemanak, "Abstract Architecture," in Abstract Software Specification. Berlin: Springer - Verlag, pp. 437 - 453, 1980. [70] M. M. Zloof, Query-By-Example: Operations on Transitive Closure. Yorktown Heights, NY: IBM, RC 5526, 1975.
[1]
N iem i, T. and Järvelin, K., O peration-O riented Q uery Language
A
[2]
A graw al, R., A lpha: A n Extension of RelationalA lgebra to Express a Class of
R
[3]
Rosenthal, A ., Heiler, S., Dayal, U. and M anola, F., TraversalRecursion: A
P
[4]
W arren, D.H.D., Efficient Processing of Interactive Relational
D
[5]
Kellog, C., O 'Hare, A . and Travis L., O ptim izing the rule-data
I
[6]
Bocca, J., EDUCE: a M arriage of Convenience: Prolog and a
R
[7]
N apheys, B. and Herkim er, D., A Look at Loosely-coupled Prolog/Database
S
[8]
Banchilon, F. and Ram akrishnan, R., Perform ance Evaluation of Data Intensive
L
[9]
Leung, Y.Y. and Lee D.L, Logic A pproaches for Deductive
D
[10]
Ullm an J.D., Principles of Database and Know ledge-base System s, vol.1,
C
[11]
Pereira, F.C.N . and W arren, D.H.D., Definite Clause Gram m ars for Language
A
[12]
A bram son, H. and Dahl, V ., Logic Gram m ars, Springer-V erlag,
[13]
M issikoff, M . and W iederhold, G., Tow ards a Unified A pproach for Expert and
D
53
[14]
DeW itt D.J. et al., Im plem entation Techniques for M ain M em ory Databases,
P
[15]
Parsaye, K., Logic Program m ing and RelationalDatabases, Database
E
[16]
A m ble, T., Logic program m ing and Know ledge Engineering, A ddison-W esley,
W
[17]
Lucas, R., Database A pplications Using Prolog, Ellis Horw ord, Chichester
[18]
Bancilhon, F. and Khoshafian, S., A Calculus for Com plex
O
[19]
Bancilhon, F., Briggs, T., Khoshafian, S. and V alduriez, P.,
F
[20]
Bjørner, D. and Jones, C.B. (Eds.), The V ienna Developm ent
M
[21]
Jones C.B., System atic Softw are Developm ent Using V DM ,
P
[22]
N iem i, T. and Järvelin, K., V DM -like Prolog Program m ing for RelationalDatabases, Proc. of the W orkshop on A lternatives of Logic Program m ing, Kuopio, Finland, pp. 148-159 (1989).
[23]
N iem i, T. and Järvelin, K., Prolog-Based M eta-Rules for RelationalDatabase
R
[24]
Tsur, S. and Zaniolo C., LDL: A Logic-based Data-language,
P
[25]
Beeri, C., N aqvi, S., Ram akrishnan R., Shm ueliO . and Tsur S., Sets and
N
[26]
Sterling, L. and Shapiro, E., The A rt of Prolog, The M IT Press (1986).
[27]
Clocksin, W . and M ellish, C., Program m ing in Prolog, Springer - V erlag
[28]
Yokom oriT., A Logic Program Schem a and its A pplications,
P
[29]
M cCord, M ., N aturalLanguage Processing in Prolog. In:
W
[30]
H. Zem anak, A bstract A rchitecture, In: A bstract Softw are Specification,
S
[31]
P. N aur, Form alization in Program Developm ent, BIT, vol. 22, no. 4, 437 -
4
[32]
N iem i, T., A Seven-tuple Representation for Hierarchical
D
[33]
N iem i, T. and Järvelin, K., A Straightforw ard Form alization
o
[34]
Schkolnik, M . and Tiberio, P., A N ote on Estim ating the M aintenance Cost in a RelationalDatabase, IBM Research Laboratory, San Jose, CA , Report RJ 3327 (40084) (1981).
[35]
Teorey, T.J. and Fry, J.R., Design of Database Structures, Prentice-Hall,
[36]
W arshall, S., A Theorem on Boolean M atrices, J. A CM , vol. 9 no.1, 11-12
E
54
[37]
W arren, H.S., A M odification of W arshall's A lgorithm for the Transitive
C
[38]
Ioannidis, Y.E., O n the Com putation of the Transitive Closure of Relational
O
[39]
Lu, H., M ikkilineni, K. and Richardson, J.P., Design and Evaluation of
A
[40]
Lu, H., N ew Strategies for Com puting the Transitive Closure of a Database
R
[41]
A graw al, R. and Jagadish, H.V ., Direct A lgorithm s for Com puting the
T
[42]
A graw al, R., Borgida, A . and Jagadish, H.V ., Efficient M anagem ent of
T
[43] First
C. Zaniolo, Prolog: A Database Q uery Language for all Seasons, Proc. The InternationalW orkshop on Expert Database System s (Ed. by L. Kerschberg),
B
[44] the
Bitton, D., The Effect of Large M ain M em ory on Database System s, Proc. of A CM SIGM O D Conf., W ashigton, pp. 337-339 (1986).
[45]
E. Sciore, Database Facilities for Prolog, Tech. Rep. 85/012, Dept of
C
[46]
E. Sciore and D.S. W arren, Tow ards an Integrated Database-Prolog System ,
P
[47]
C.L. Chang and A . W alker, PRO SQ L: A Prolog Program m ing Interface w ith
S
[48]
M aier, D., The Theory of RelationalDatabases. Pitm an, London, 1984.
[49]
Jagadish, H.V . and A graw al, R., A Study of Transitive Closure as Recursion
M
[50]
N iem i, T. and Järvelin, K. A dvanced Q uery Form ulation in Deductive
D
1.
Abiteboul, S., and Bidoit, N. Non first normal form relations to represent hierarchically organized data. In Proceedings of the 3rd ACM Symposium on Principles of Database Systems (Canada, Ontario, Waterloo, April, 1984), pp. 191-200.
2.
Agrawal, R. Alpha: An extension of relational algebra to express a class of recursive queries. In the 3rd IEEE Conference on Data Engineering (Los Angeles, Feb. 3-5, 1987) pp. 580-590.
3.
Bancilhon, F., Richard, P., and Scholl, M. On line processing of compacted relations. In Proceedings of the 8th VLDB Conference (Mexico City, Sept., 1982), pp.263-269.
4.
Bancilhon F., and Khoshafian S. A calculus for complex objects. In Proceedings of the 5th ACM Symposium on Principles of Database Systems (Cambridge, Massachusetts, March, 1986), pp. 53-59.
55
5.
Bancilhon F., Briggs T., Khoshafian S., and Valduriez P. FAD, a powerful and simple database language. In Proceedings of the 13th VLDB Conference (Brighton, 1987), pp. 97-105.
6.
Barbara, D., Garcia-Molina, H., and Porter, D. A probabilistic data model. Vol.416. In Lecture Notes in Computer Science. Springer-Verlag, 1990.
7.
Beeri, C., Naqvi, S., Ramakrishnan, R., Shmueli, O., and Tsur, S. Sets and negation in logic database language (LDL1). In Proceedings of the 6th Symposium on Principles of Database Systems (San Diego, March, 1987), pp. 21-37.
ACM 8.
Bitton, D. The Effect of large main memory on database systems. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Washington, D.C., May , 1986), pp. 337-339. 9.
Bjørner, D. and Jones, C.B. (Eds.) The Vienna Development Method: the meta language. Vol.61. In Lecture Notes in Computer Science. Springer-Verlag, 1978.
10.
Chen, Q., and Gardarin G. An implementation model for reasoning with complex objects. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Chigago, Illinois, June 1-3, 1988), pp. 164-172.
11.
Chen, Q., and Kambayashi Y. Nested relation based database knowledge representation. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Denver, Colorado, May 29-31, 1991), pp. 328-337.
12.
13.
Colby, L.S. A recursive algebra and query optimization for nested relations. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Oregon, May 31-June 2, 1989), pp. 273-283. Dadam, P., Kuespert, K., Andersen, F., Blanken, H., Erbe, R., Guenauer, J., and Lum, V. A dbms prototype to support extended NF2relations: an integrated view on flat tables and hierarchies. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Washington, D.C., May , 1986), pp. 356-367.
14. 14,
Date, C. A critique of the sql database language. ACM SIGMOD Record 3 (1984), 8-54.
15.
Desai, B.C., Goyal, P., and Sadri, F. Non-first normal form universal relations: an application to information retrieval systems. Information Systems 12, 1 (1987), 49-55.
16.
Deshpande, V., and van Gucht, D. An implementation for nested relational database. In Proceedings of the 14th VLDB Conference (Los Angeles, Calif., Aug. 29-Sept. 1, 1988), pp.76-88.
56
17.
DeWitt, D.J., Katz, R.H., Olken F., Shapiro, L.D., Stonebraker, M.R., and Wood D. Implementation techniques for main memory databases. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Boston, Mass., June 1984), pp. 1-8. 18.
Diller, A. Z an introduction to formal methods. John Wiley & Sons, 1990.
19.
Gyssens, M., and Van Gucht, D. The powerset algebra as a result of adding programming constructs to the nested relational algebra. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Chigago, Illinois, June 1-3, 1988), pp. 225-232.
20.
Hughes, J. Object-oriented Databases. Prentice Hall, New York, 1991.
21.
Hulin, G. On restructuring nested relations in partitioned normal form. In Proceedings of the 16th VLDB Conference (Australia, Brisbane, Aug. 13 16, 1990), pp.197-207.
22.
23.
24.
Iwaihara, M., Furukawa, T., and Kambayshi, Y. Navigation and schema transformations for producing nested relations from networks. In the 7th IEEE Conference on Data Engineering (Japan, Kolbe, April 8-12, 1991) pp. 181-190. Jaeschke, G., and Scheck, H.-J. Remarks on the algebra of non first normal form relations. In Proceedings of the 1st ACM Symposium on Principles of Database Systems (Los Angeles, Calif., 1982), pp. 124-138. Jhingran, A. Precomputation in a complex object environment. In the 7th IEEE Conference on Data Engineering (Japan, Kolbe, April 8-12, 1991) pp. 652-659.
25.
Jones C.B. Systematic Software Development Using VDM. Prentice Hall , New York, 1986.
26.
Järvelin, K., and Niemi, T. An entity-based approach to query processing in relational databases Part I: entity type representation. Data & Knowledge Engineering. 10 (1993), 117-150.
27
Järvelin, K., and Niemi, T. An entity-based approach to query processing in relational databases Part II: entity query construction and updating. Data & Knowledge Engineering. 10 (1993), 151-186.
28.
Kemper, A., Lockeman, P.C., and Wallroth M. An object-oriented database systems for engineering objects. In Proceedings of the ACM SIGMOD International Conference on Management of Data (San Francisco, May , 1987), pp. 299-310.
29.
Kemper, A., and Wallroth, M. A uniform concept for storing and manipulating engineering objects. Vol.334. In Lecture Notes in Computer Science. Springer-Verlag, 1988.
57 30.
Korth, H.F. Optimization of object-retrieval queries. Vol.334. In Lecture Notes in Computer Science. Springer-Verlag, 1988.
31. Systems
Kuper, G.M., and Vardi, M.Y. A new approach to database logic. In Proceedings of the 3rd ACM Symposium on Principles of Database (Canada, Ontario, Waterloo, April, 1984), pp. 86-96.
32.
Kuper, G.M. Logic programming with sets. In Proceedings of the 6th ACM Symposium on Principles of Database Systems (San Diego, March, 1987), pp. 11-20.
33.
Linneman, V. Non first normal form relations and recursive queries: An sqlbased approach. In the 3rd IEEE Conference on Data Engineering (Los Angeles, Feb. 3-5, 1987), pp. 591-598.
34.
Maier, D., Ullman, J.D., and Vardi, M.Y. On the foundations of the universal relation model. ACM Trans. Database Syst. 9, 2 (1984), 283-308.
35.
Niemi, T. A seven-tuple representation for hierarchical data structures. Information Systems. 8, 3 (1983), 151-157.
36.
Niemi, T., and Järvelin, K. Prolog-based meta-rules for relational database representation and manipulation. IEEE Transactions on Software 17, 8 (1991), 762-788.
Engineering 37.
Niemi, T. and Järvelin, K. Operation-oriented query language approach for recursive queries-part1. functional definition. Information Systems. 17, 1 (1992), 49-75.
38.
Niemi, T. and Järvelin, K. Operation-oriented query language approach for recursive queries-part2. prototype implementation and its integration with relational databases. Information Systems. 17, 1 (1992), 77-106.
39.
Niemi, T. and Järvelin, K. Advanced query formulation in deductive databases. Information Processing & Management. 28, 2 (1992), 181-199.
40.
Ohori, A., Buneman, P., and Breazu-Tannen, V. Database programming in Machiavelli - a polymorphic language with static type inference. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Oregon, May 31-June 2, 1989), pp. 273-283. 41.
Ozsoyogly, Z.M., and Yuan, L. A new normal form for nested relations. ACM Trans. Database Syst. 12, 1 (1987), 111-136.
42.
Paredaens, J., and van Gucht, D. Converted nested algebra expressions into flat algebra expressions. ACM Trans. Database Syst. 17, 1 (1992), 65-93.
43.
Paul, H.P., Scheck, H.J., Scholl, M.H., Weikum, G., and Deppish, U. Architecture and implementation of the Darmstadt database kernel In Proceedings of the ACM SIGMOD International Conference on Management of Data (San Francisco, May, 1987), pp. 196-207.
system.
58 44.
45.
Pistor, P., and Andersen F. Designing a generalized nf2 model with an sqltype language interface. In Proceedings of the 12th VLDB Conference (Kyoto, Japan, Aug., 1986), pp.278-285. Roth, M.A. Theory of non-first normal form relational databases. Ph. D. dissertation, Univ. of Texas, Austin, 1986.
46.
Roth, M.A., Korth, H.F., and Batory, D,S. SQL/NF: a query language for ¬ 1NF relational databases. Information Systems. 12, 1 (1987), 99-114.
47.
Roth, M.A., Korth, H.F., and Silberschatz, A. Extended algebra and calculus for nested relational databases. ACM Trans. Database Syst. 13, 4 (1988), 389-417.
48.
Scheck, H. - J., and Pistor, P. Data structures for an integrated data base management and information retrieval system. In Proceedings of the 8th VLDB Conference (Mexico City, Sept., 1982), pp.197-207.
49.
Scheck, H. - J., and Scholl, M.H. The relational model with relation-valued attributes. Information Systems 11, 2 (1986), 137-147.
50.
Scheck, H. - J., Paul, H.B., Scholl, M.H., and Weikum, G. The DASDBS project: objectives, experiences, and future prospects. IEEE Trans. Knowledge Data Eng. 2, 1 (1990), 25-43.
51.
Shu, N.C., Lum, V.Y., Tung F.C., and Chang C.L. Specification of forms processing and business procedures for office automation. IEEE Trans. Softw. Eng. 8, 5 (1982), 499-512.
52.
Stemple, D., Fegeras, L., Sheard, T., and Socorro, A. Exceeding the limits of polymorphism in database programming languages. Vol.416. In Lecture Notes in Computer Science. Springer-Verlag, 1990.
53.
Südkamp, N., and Linnemann, V. Elimination of views and redundant variables in an SQL-like database language for extended nf2 structures. In Proceedings of the 16th VLDB Conference (Australia, Brisbane, Aug. 13 16, 1990), pp.302-313.
54.
Thomas, S.J., and Fisher, P.C. Nested relational structures. In Advances in Computing Research III, The Theory of Databases, P.C. Kanellakis, Ed. JAI Press, Greenwich, Conn., 1986, pp. 269 - 307.
55.
Tansel, A.U., and Garnett, L. Nested historical relations. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Oregon, June, 1989), pp. 284-293.
56.
Tsur, S., and Zaniolo C. LDL: a logic-based data-language. In Proceedings of the 12th VLDB Conference (Kyoto, Japan, Aug., 1986), pp.31-41.
59
