An Incremental Query Compiler with Resolution of Late Binding

Transcription

1 An Incremental Query Compiler with Resolution of Late Binding Staffan Flodin Abstract This paper presents the extensions made to the query compiler of an object-relational database management system (ORDBMS) to make it function incrementally and to make it resolve when late binding of function calls must be used. The object-oriented model consists of features such as operator overloading and inheritance which leads to the requirement of late binding of function calls. Late binding is not desirable since it can lead to inefficient execution plans due to the difficulty of optimizing late bound calls. Therefore a resolution mechanism of late binding, which recognize the unavoidable cases of late binding is very desirable. This resolution mechanism decides if early binding cannot be used and only then suggests late binding. Having the system to resolve when late binding must be used, the order in which functions are defined becomes significant to the consistency of the system. To make the system maintain consistency the query compiler needs to function incrementally and recompile existing functions whenever required. This work has been supported by The Swedish National Board for Industrial and Technical Development (NUTEK) and The Center for Industrial Information Technology. IDA Technical Report 1994 LiTH-IDA-R ISSN Department of Computer and Information Science, Linköping University, S Linköping, Sweden

2 An Incremental Query Compiler with Resolution of Late Binding by Staffan Flodin Dept. of Computer and Information Science Linköping University Linköping, Sweden Abstract This paper presents the extensions made to the query compiler of an object-relational database management system (ORDBMS) to make it function incrementally and to make it resolve when late binding of function calls must be used. The object-oriented model consists of features such as operator overloading and inheritance which leads to the requirement of late binding of function calls. Late binding is not desirable since it can lead to inefficient execution plans due to the difficulty of optimizing late bound calls. Therefore a resolution mechanism of late binding, which recognize the unavoidable cases of late binding is very desirable. This resolution mechanism decides if early binding cannot be used and only then suggests late binding. Having the system to resolve when late binding must be used, the order in which functions are defined becomes significant to the consistency of the system. To make the system maintain consistency the query compiler needs to function incrementally and recompile existing functions whenever required. 1

3 1.0 Introduction This paper describes the extensions made to a query processor to make it function incrementally and to make it resolve when function calls need to be late bound. The extensions are implemented in an existing system, AMOS [4], an Object-Relational database management system that serves as a research platform. An Object-Relational database management system is an Object-Oriented [1] system with a relationally complete query language. AMOS is based on the functional datamodel of DAPLEX [9] and has a highlevel declarative query language; AOMSQL. Functions are used to represent properties of objects, both stored and derived properties. The Object -Oriented model includes features such as operator overriding in combination with late binding and inheritance in the type hierarchy. Late/early binding is referring to the time when a function name is bound to a particular implementation, i.e. resolvent. Having late bound function calls in the execution plan of a database query should be avoided since: The overhead of type resolution at runtime increases the execution time It is hard to produce a good optimization of the query. The latter problem stems from the fact that the resolvent must be chosen at runtime in case of late binding. Thus the optimizer has no knowledge of what the execution cost will be when the query is optimized, i.e. at compile time. Late binding is however desirable to have in the execution model since that enhances the modelling capabilities of the language. It is therefore important to allow late binding but to use early binding whenever possible and only bind late when early binding cannot be used. Thus, having the query processor to resolve when early binding cannot be used and only then bind late is very desirable. Introducing this resolution mechanism into the query processor of a database makes the order in which functions are defined significant. Furthermore redefinition, and deletion, of functions must also be considered otherwise the database schema might become inconsistent or invalid. Thus, the query processor must be extended to function incrementally to recompile the affected functions whenever any of these events occur. The outline of this paper is as follows: In section 2.0 an overview of some Object-Oriented concepts is given. Then, in section 3.0 the resolution mechanism for late binding is described along with some examples. In the same section a description of how the query compiler is extended to function incrementally is given. In the end of section 3.0 a description of changes in the query language due to the resolution mechanism is given. Finally in section 4.0 contains a summary and future work is pointed out. 2.0 Object-Oriented database system A database system is said to be Object-Oriented if certain features are supported. In [1] a definition of an object-oriented database system is given. This definition states that a database management system is object-oriented if: It is a database management system (DBMS) It is an object-oriented system A DBMS is a system that supports the management of a database. An object-oriented system supports Complex objects Object identity Encapsulation Types (Classes) Inheritance Overriding combined with late binding Extensibility 2

4 Computational completeness The term operator overloading is used in this paper and it refers an operator name that has several implementations. Redefinition of an inherited operator is operator overriding. Operator overriding is a special case of operator overloading. In this paper we are only concerned with types, inheritance and overloading in combination with late binding. 2.1 Types A type 1 in an object oriented system summarizes the common features of a set of objects with the same characteristics. It corresponds to the notion of an abstract data type. A type consists of an interface and an implementation. The interface consists of a set of operations with their signatures, i.e. the argument and result type. Types are generally used at compile time to check a certain degree of correctness of a program. 2.2 Inheritance The types are organized in a hierarchy according to a subtype relation. We say that a type t i is a subtype of type t j or that t j is a supertype of type t i. Over this subtype - supertype relation there is inheritance. A subtype inherits all of its supertype s properties. The subtype - supertype relation can also be seen as a specialization - generalization relation [10]. Since a subtype can only add or specialize existing properties of its supertype it can be seen as a specialization. As an example consider the following type tree Person Name(Person)->Charstring Ssno(Person)->Charstring Student Employee Dept(Employee)->Department Course(Student)->Course Supervisor Supervises(Supervisor)->Department Figure 1 Type tree The type Person has two interface functions 2, Name and Ssno. The type Employee is a subtype of type Person whereby it inherits all properties from type Person. Another consequence of type Employee being a subtype of type Person is that all instances of type Employee are also instances of type Person. This has the consequence that all functions defined in the interface of type Person can be applied to instances of type Employee. The type Supervisor inherits from Employee and through Employee it inherits from Person. Hence the inheritance relation is transitive. If a type is a subtype of more than one type we have multiple inheritance. Multiple inheritance can cause problems if a type inherits two functions with the same name from different supertypes. In such cases some sort of conflict resolution mechanism is required to guide the selection of resolvent. 1. In some systems the notion of class is used instead of type. In this paper the notion of type is used. 2. The term method or operation is used by others, we prefer the notion of function 3

5 2.3 Operator overloading Operator overloading is a feature of using the same name to denote different operations when applied to different types of objects [3] or attach more than one meaning to a name appearing in a program [8]. In this paper we are only concerned with the overloading of function names. If a name is overloaded in a subtype - supertype relation there is an overriding of that name in the subtype. The following definitions in OSQL [6] define three functions with the same name but with different implementations. create function income(person p)->integer j as stored; create function income(student s)->integer j as select 0; create function income(supervisor s)->integer as select times(2,maxsal) for each integer maxsal, employee e where maxsal=maxagg(person.income(e)); Figure 2 An overloaded function income The above definitions overload the name income with three resolvents, instances of the same name. Each resolvent can be identified by its signature. A function signature is an annotation of the function name with the type names of its formal parameter and its resulting type name. In the above example we have the resolvents income Person integer, income student integer that are stored functions and a derived function resolvent income supervisor integer. 2.4 Polymorphism Polymorphism means ability to take several forms. Polymorphism is often controlled by inheritance by the type compatibility rule [8] which says that an assignment a:=b where a is of type A and b is of type B is only legal if B is a subtype of A. It is often useful to speak of static type and dynamic type of a reference where the former is the declared type and the latter is the type of the object referenced at runtime. The set of possible dynamic types of a given reference is the set of all subtypes of the static type of the reference. We refer this set as the dynamic type set. In this paper S(arg) denotes the static type of a reference arg, D(arg) denote the dynamic type and T(t i ) denote the dynamic type set of a type t i. To exemplify S(arg) and D(arg) consider the definitions in figure 2 and the type hierarchy in figure 1. The following holds: S(person.income)=person S(maxsal)=integer T(p)={person, student, employee, supervisor} D(p)=t i t i T(p) The last example holds since reference p is declared to be of type person. 2.5 Late binding Late binding [5] [8], also called dynamic binding, is having the dynamic type of a reference to determine the choice of resolvent. Consider the example in figure 1, When querying the database over all instances of Person we are also interested in objects of type Student, Employee and Supervisor. If we are interested in the names of all objects of type Person we write: select name(p) for each person P; 4

6 In above example the function name can be early bound to the resolvent name person charstring. When the dynamic type of the reference P is coerced to subtypes of type Person the resolvent name person charstring is applicable since it is inherited to the subtypes of type Person. Consider another example, now in the context of figure 2. If we are interested in the salaries of all persons we would query the database with the OSQL query select income(p) for each person P; As in the previous example we are interested in the salaries of instances of Student, Employee and Supervisor. Since function Income is redefined in some subclasses of Person a resolvent cannot be selected at compile time, thus the function income has to be late bound. Binding late here means that each time Income is applied to its parameter P the dynamic type of P has to be determined and a resolvent has to be chosen on the basis of the dynamic type. In a regular programming language this means a considerable decrease in performance and in a database query language it might be even worse since optimization of the query is very important and with late bound functions in the execution plan it is hard to do good optimization. 3.0 Query compilation in AMOS AMOS [4] is a next generation object-oriented database management system prototype under development at our department. AMOS supports among other features: overloading, inheritance, late binding, early binding. A restriction is that AMOS currently supports overloading on the first argument type only. When functions are created in AMOS then query compilation is invoked. Query compilation is done in several steps as shown below: Parse Flattener Type Check Transl. Algebr. Query Optimize Figure 3 Query Compilation In AMOS the algebraic query form is an ObjectLog [5] program. During the translation to ObjectLog all derived function 1 [5] calls are substituted by their bodies in the function being compiled and the expanded query is then optimized, i.e. global optimization. In this paper we are interested in the type checking phase of the query compilation. 3.1 Derivation of late binding Late binding should be avoided due to the decrease in performance caused by the overhead of runtime resolution of resolvents and the difficulties of optimizing late bound calls. Therefore a derivation mechanism for late binding has been implemented in AMOS. The derivation mechanism must recognize the cases where the use of early binding is not possible and only then suggest late binding. The derivation is 1. A derived function is defined as a query, corresponds to a view in the relational model 5

7 performed in the flattening phase (see figure 3) when a function call is to be bound to a resolvent. In the remaining of this section this derivation mechanism is described. Let t j denote an arbitrary type, t i.fn a resolvent of a function name fn in the interface of type t i, S(x) a function returning the static type of reference x. A fundamental condition for late binding to be required is that the name must be overloaded. This condition can be formulated as overloaded(fn) t j.fn t i.fn [S(t i.fn) S(t j.fn)] If the name is overloaded, the type hierarchy has to be examined since overloading alone does not imply that late binding is required. To be able to examine the type hierarchy a subtype-of operator must be defined. Let < denote subtype-of relation where the following holds t i < t j if t i is a subtype of t j, t i t j if t i < t j or t i = t j. In order to specify in which subtree the subtype-of relation holds between two types the subtype-of relation is specialized to subtype-of relative to a type. Let t i < tk t j denote this relation where t i is a subtype of t j relative to a type t k. This relation is defined as: t i < tk t j t i < t j (t i > t k t k > t i ) (t j > t k t k > t j t k = t j ) t i tk t j t i < tk t j t k = t j To exemplify the usage of the subtype-of relative relation consider the type tree below: t a t b t c t d Figure 4 Type tree In the type tree in figure 4 the following are correct statements: t b < t a holds. t b < ta t a holds t b < tc t a does not hold since (t b > t c t c > t b )is false. t d < tc t a holds 6

8 These relations can now be used to define when early binding cannot be used. Early binding of a function call fn(arg) cannot be used if there exists at least one redefinition of fn in the dynamic type set of the static type of argument arg and there exists a resolvent of fn which is applicable to the static type of the argument. Formally 1 : Late(fn(arg 1.. arg n )) t j.fn t k.fn[s(t j.fn) < S(arg1) S(t k.fn) S(arg 1 ) S(tk.fn) S(t k.fn)] As an example of the above rule consider the following type tree: t a t a.fn t b t b.fn tc t d Figure 5 Type tree Function gn is defined as create function gn(t c arg 1 )->restype as select fn(arg 2 ) for each t c arg 2 where... This creates a derived function gn that uses an overloaded function fn. Function fn is overloaded since t j.fn,t i.fn[t i t j ] holds. Derivation of late binding means evaluating the expression late(fn(arg 2 )) which is equal to the expression: t j.fn t k.fn[s(t j.fn) < S(arg1) S(t k.fn) S(arg 1 ) S(tk.fn) S(t k.fn)] This expression cannot be satisfied. The conjunct S(t j.fn) < S(arg1) S(t k.fn) where S(t j.fn)=t b and S(arg 2 )=t c does not hold because (t b > t c t c > t b ) is false, thus the function call to fn can be early bound to resolvent t a.fn. If a resolvent t d.fn had been created before compilation of gn the formula would hold and fn would be bound late in gn. If on the other hand t d.fn is created after gn problems arise, thus the order in which the functions are defined has become significant due to the resolution mechanism. 3.2 Query recompilation In AMOS global query optimization is used. This has the consequence that if a function gn uses function fn and fn is changed then function gn must be recompiled to use the new implementation of function fn. Derivation of late binding is not enough to make the binding policy transparent since the order in which functions are created must be considered. Thus, a mechanism for query recompilation must be devised. It is very important to find the minimal set of functions to recompile since the overhead of recompilation can be considerable. When a function gn is changed the system must respond to this change. If a change of a function is not responded to then the schema might be left in an inconsistent or erroneous state. 1. Note that only S(arg 1 ) is considered. The reason is the current limitation to overloading on the first argument type. 7

9 A change to a function can be the introduction of a new resolvent, a deletion or a redefinition of a resolvent to that function name If the static type of the changed resolvent is a subtype to the static type of any other resolvent relative the static type of its argument then recompilation of all functions using the other resolvent must be performed, i.e. the following must hold: t j.fn[s(t j.fn)>s (ti.fn) S(t i.fn)] where t i.fn is the new resolvent. To find the functions that are affected due to a new or changed resolvent, a relation between functions that specifies which functions using a resolvent is needed. Let usedbyfunction(fn) be such relation from a resolvent to a set of resolvents: usedbyfunction:r R * where R is the set of resolvents in the database schema. Consider the following example to illustrate the usedbyfunction relation. create function salary(person p)->integer as stored; create function dept(person p)->department as stored; create function bestpayed(department d)->integer as select maxagg(( select salary(p) for each person p where dept(p) = d)); create function topsalaries()->integer as select maxagg((select bestpayed(d))) for each department d; create function AtTheTop(person p)->boolean as select salary(p)=bestpayed(dept(p)) for each department d where bestpayed(d)=topsalaries(); In above example the following holds: usedbyfunction(person.salary) = {department.bestpayed} usedbyfunction(person.dept) = {department.bestpayed} usedbyfunction(department.bestpayed) = {.topsalaries} usedbyfunction(person.atthetop) = {person.salary department.bestpayed person.dept.topsalaries} The set of functions that needs to be recompiled when a new resolvent t i.fn is created, denoted rec(t i.fn), is retrieved by taking the transitive closure of the usedbyfunction relation. The above set rec(t i.fn) has to be sorted into a sequence according to the usedbyfunction relation before recompilation., i.e t j.gn usedbyfunction(t p.fn) then t j.gn must be recompiled before t p.fn. The functions in this list are then recompiled. Computing this relation can be done efficiently by allowing each function object to have a set of pointers to other function objects using it, i.e. each function object contains its usedbyfunction relation. 3.3 Incremental query compiler To provide the user a totally incremental query compiler then it must be possible to redefine existing functions. Previously, recompilation in AMOS involved deletion of a function object and then creation of another function object with the same signature. Deletion of a function object leads to the deletion of all functions using the deleted function. Now, redefining a function object keeps the same object identification (OID) but changes the content. Instead of deletion of all functions using the redefined function recompilation is used. This is very easy to achieve once query recompilation is implemented since it is essentially the same procedure. Use the usedbyfunction relation on the redefined function to get the set of functions to recompile and recompile them. 8

10 Deletion of functions might also cause recompilation of other functions or even deletion. When a function resolvent is deleted, all functions that are using the deleted function must be recompiled to choose another resolvent if possible. If it is not possible then that function must also be deleted. The function to recompile is achieved by the usedbyfunction relation. If a function is deleted that overrides another resolvent it may be the case that a late bound call to that function name can be substituted by an early bound call to a resolvent. As mentioned there are three events that the query compiler must respond to in order to function incrementally, these are: Definitions, redefinition and deletions of resolvents. Definition of a new resolvent t j.fn. When a new resolvent is defined there exists a possibility that function calls using early binding of function fn must be change the binding to late binding. This only occurs when the new resolvent t j.fn overrides another resolvent t i.fn. Recall that overriding is redefining in a subtype. Thus, the set of resolvents to be recompiled is obtained by rec(t i.fn) where t i.fn is the overridden function, i.e. S(t i.fn) S(tj.fn) S(t j.fn). Redefinition of a resolvent t j.fn. All functions using the redefined resolvent must be recompiled. The set of functions to be recompiled is then obtained by rec(t j.fn). Deletion of a resolvent t j.fn Deletion of a resolvent t j.fn that overrides another resolvent t i.fn can have the consequence that late bound calls to fn can be converted to early bound calls to t i.fn. This is possible when the deleted resolvent t j.fn overrides another resolvent and t j.fn is itself not overridden by a third resolvent. Deletion of a resolvent may also cause other resolvents to be deleted. If the deleted resolvent t j.fn does not override another resolvent then all resolvents t k.gn that binds t j.fn early will be deleted since there is no resolvent of fn that can be inherited to type t j. The same holds for all calls to fn(arg) that are late bound with t j S(arg) and S(arg) S(t k.fn) where t k.fn overrides t j.fn. The resolvents to be recompiled is obtained by rec(t j.fn). When the set of resolvents obtained from rec(t j.fn) is recompiled then type errors might occur as described previously. These errors are trapped and the resolvent is deleted instead and the functions using it must be recompiled. With a query compiler that detects these events and respond to them, a fully incremental query compiler has been obtained. 3.4 Changes in the query language The query language of AMOS, AMOSQL, had a construct late(fn) by which the programmer declared which functions that were to be bound late. The problems with this approach are many. The programmer must be aware of all overloaded function names and he must also be aware that existing functions might have to be redefined when a new resolvent is introduced. Furthermore, redefining a function meant deleting it which lead to cascaded deletion of all functions using it. The main advantage of late binding is that the programmer has full control when late binding is used. With derivation of late binding, the AMOSQL construct late(fn) is no longer required in the language. The case where the difference is really important is when defining recursive functions. Consider the following AMOSQL definitions create type employee; create type supervisor subtype of employee; create type manager subtype of supervisor; 9

11 create function income(employee e)->integer as stored; create function income(supervisor s)->integer as select maxagg(income(e)) for each employee e; create function income(manager m)->integer as select 10*maxsal for each employee e where maxsal=maxagg(income(e)); When manager.income is compiled the call to income will be bound late. When executing the query e will be coerced to supervisor and manager and we have an infinite loop. The solution is to use fully qualified references in such cases. A fully qualified reference is the complete name of the desired resolvent. The correct OSQL function definition is given below. create function income(manager m)->integer as select 10*maxsal for each employee e where maxsal=maxagg(employee.income(e)); Notice that qualification only involves the first argument type. 4.0 Summary and future work As mentioned throughout this paper optimization of late bound function calls is a problem. The problem is that the current optimization is a global optimization done at compile time. Since the resolvents of late bound function calls are not known at compile time the correct body cannot be substituted into the currently compiled function. In [7] a survey over existing systems is given and the conclusion is that currently no satisfactory technique exists for optimizing late bound function calls. Our goal is to find a satisfactory model for optimization of late bound function calls. With a solution to this problem in combination with the resolution mechanism and incrementality described in this paper full advantage can be taken from the expressiveness of the Object-Oriented model without having to consider any performance decrease caused by having late bound function calls. As a possible continuation when the optimization problem of late binding has a satisfactory solution is to generalize the solution to optimization of functions overloaded on all argument types, result type included. 10

12 References 1. Atkinson, M., Bancilhon, F., DeWitt, D., Dittrich, K., Maier, D., Zdonik, S., The Object-Oriented Database System Manifesto, Proc. of the 1st Intl. Conf. on Deductive and Object-Oriented Databases, Kyoto, Japan, Dec Dayal, U., Queries and Views in an Object-Oriented Data Model, Proc. 2nd Intl. Workshop on Database Programming Languages, Elmasri, R. and Navathe, S., Fundamentals of Database Systems Benjamin/Cummings, Fahl, G., Risch, T., Sköld, M., AMOS - An Architecture for Active Mediators Proc. Intl. Workshop on Next Generation Information Technologies and Systems, Haifa, Israel, June Litwin, W. and Risch, T., Main Memory Oriented Optimization of OO Queries using Typed Datalog with Foreign Predicates, IEEE Transactions on Knowldge and Data Engineering, Vol 4, No. 6, December Lyngbaek, P., OSQL: A Language for Object Databases, Technical Report HPL-DTD-91-4, Hewlett-Packard Company, Mayer, D., Daniels, S., Keller, T., Vance, B., Graefe, G., McKenna, W., Challenges for Query Processing in Object-Oriented Databases., Query Processing for Advanced Database Systems, Morgan Kaufmann Publishers, Meyer, B., Object-Oriented Software Construction, Prentice Hall, Shipman, D.W., The Functional Data Model and the Data Language DAPLEX, ACM Transactions on Database Systems, Vol. 6, No. 1, March Straube, D.D. and Özsu, M.T., Queries and Query Processing in Object-Oriented Database Systems, ACM Trans. on Information Systems, Vol. 8, No. 4, October