Database Programming Languages (DBPL-5)

In this paper we investigate union-types in object oriented IQL-like schemas. These types can be used to model null values, variant types and generalization classes. They make, however, deciding equivalence and subtyping more dif-ﬁcult. We will show that the complexity of these two problems is co-NP-complete and present complete sets of rules for deciding both problems. The combination of union-types and multiple inheritance makes it also harder to detect typing-conﬂicts in a schema. We will give an algorithm for deciding this and discuss its complexity. Furthermore, we will present an algorithm for detecting schemas that deﬁne types with a bounded number of values. Finally, an algorithm will be presented that veriﬁes whether in a schema the type of a subclass speciﬁes options that are forbidden by its superclasses.


Introduction
The introduction of union-types in object-oriented schemas makes them more expressive. Usually, however, they are limited to disjoint unions [9] or labeled unions such as variant records [7]. Because of this limitation the reasoning about these types remains simple [6,13]. We argue that general union-types such as used in [10,2,5] are a useful extension and even arise naturally in data models without union-types.
We can use them, for instance, to model optional integer fields by specifying their type as (null_ int) where null is a special basic type with only one value viz. null. Moreover, we could define several kinds of nulls and let the type be (null unkn _ null undef _ int). If an object has two fields that are both optional we might want to specify that one of them has to be defined but not both. This can be done by giving the object's class the tuple-type ([a : int; b : null] _ [a : null; b : str]) 1 . This is an example of how in general it is possible to represent variant records.
In data models that do not have union-types such as in [1] they arise naturally in the context of multiple inheritance. They can, for instance, be used to denote generalization classes without explicitly adding them to the schema. This can be demonstrated by the schema depicted in Figure 1. Here we see the two classes Angler and Sea Fisherman both with the field catch which is, respectively, a set of Fish and a set of Sea Animals. Since Sea Angler is a subclass of Angler and Sea Fisherman it inherits the field catch that must be both a set of Fish and a set of Sea Animals.
The type of the catch of a Sea Angler is a set of (Mackerel _ Tuna), or with intersection-types as a set of (FishŜ ea Animal) which is actually the same type. Without union-types or intersection-types this type cannot be denoted unless an extra class Sea Fish is added that is the generalization of Mackerel and Tuna, and a subclass of Fish and Sea Animal. Although this class might seem quite natural here, this approach can lead to the addition of more unnatural generalization classes.
Although union-types give us more expressiveness they also make the reasoning about types more difficult. Different type expressions can now denote the same type. For instance, the type ( the same, the rules for union-types cannot be simply defined by induction on the type. For instance, it is not sufficient to check that type t 1 is a subtype of type t 2 or type t 3 in order to see whether t 1 is a subtype of (t 2 _ t 3 ). In this paper we present complete rules for both equivalence and subtyping, and show how they provide necessary and sufficient conditions for deciding equivalence and subtyping. This results in algorithms of which we will discuss the complexity. The presented rules are similar to those presented in [3] where it is shown how a sound and complete subtyping algorithm for union types can be obtained out of some algorithm for intersection types. An example of such an algorithm for intersection types can be found in [12]. The main difference with our work is that we do not allow general functional types but only tuple-types (which might be regarded as a very limited functional type), and that we have set-types and classes as types.
The presented reasoning rules can also be used in algorithms for detecting schemas with inconsistencies and/or improbable cases. An example of an inconsistency is where the types of a class and its superclasses are not compatible. This can be checked by taking for every class the intersection of its type and the types of all the superclasses and deciding whether this type is equivalent with ; i.e. the empty type. If this holds then the schema is inconsistent and the class will always be empty. These problems were already discussed in [4,11,14] for the more conventional object-oriented data model. For data models with union-and intersection-types they were studied in [5]. The main differences between this work and ours is that we allow types of arbitrarily nested sets and tuples but we limit the classes that an object can simultaneously belong to. Another difference is that we present algorithms for detecting schemas with improbable cases that indicate modeling errors. Finally, we will present an algorithm for checking whether the type of a subclass is a proper extension of the types of its superclasses. A type is a proper extension of another type if it does not specify options already forbidden by the other type. We say that a schema is proper iff the types specified with the classes are proper extensions of the intersection of the types of the superclasses (not including the class itself). If a schema is not proper it is likely that it 5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 contains a modeling error. For instance, if the type of a superclass is [a : ( int _ bool)] and the type of the subclass is [a : ( str _ bool)] then the str-option in the subclass is superfluous and the schema is not proper. We will give a precise semantic definition of proper extension and provide and discuss an algorithm that decides whether a type is a proper extension of another type.
The paper is organized as follows. In Section 2 we present the data model and give the semantics of the types. In Section 3 we discuss the problems of deciding equality and subtyping for types. In Section 4 we present the algorithms for detecting inconsistent schemas, bounded types and non-proper schemas.

The Data Model
The data model we use is a slight extension of the IQL data model. We will only give a brief informal description.
An instance consists of a finite set O of objects, a function valthat gives the value of every object in the instance and a function ext that gives the extension of every class. Every object in O must occur in the extension of at least one class. If an object occurs in the value of another object of O then it must also be in O. Where ; is the empty type with no values, B is the set of basic types (such as int, str, bitmap and the special type null), C is the set of class names and f 1 ; : : : ; f n with n 0 are distinct field names. Types of the form (T _ T) and (T^T ) are, respectively, called union-types and intersection types. In the following we will let the variables , , range over types, b range over basic types, c range over class names and f,g,h range over field names.
A schema describes the structure of a database instances. It consists of a finite set C of class names, a function type that gives for every class name in C a type, and the binary relationship isa that is defined between the class names in C. If a class occurs in the type of a class in the schema then it must also be in the schema. The reflexive and transitive closure of isa is denoted as isa . We say that c 1 is a direct subclass of c 2 iff c 1 isa c 2 and that c 1 is a subclass of c 2 iff c 1 isa c 2 . Moreover, c 1 is a strict subclass of c 2 if c 1 is a subclass of c 2 but c 2 is not a subclass of c 1 . Since all classes have a unique name we can safely identify classes with their names.
The semantics of a type is given by the function [ We now say that an instance belongs to a schema iff 1. the values of objects in a class are of the type of that class, 2. the extension of a class must be a subset of the extension of all its direct superclasses, and 3. an object that belongs to two classes must also belong to some common subclass of these two classes.
5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 Notice that condition 3 is equivalent with saying that for every object there is a unique class such that it belongs to this class and to all its superclasses and to no other class. This unique class is said to be the class of the object. It also follows immediately from condition 2 that the extension of a class is a subset of the extension of all its superclasses.
A schema hC; type; isai is sound if there is not a class c in C whose extension is empty in all instances of the schema.
This concludes the presentation of the data model. It must be noted here that our data model is slightly flawed because it allows values with fields which were not specified in the schema. For instance, a schema with only one class Person with type [name : str; a g e : int] might have an instance consisting of an object with the value [name : \P ete 00 ; a g e : 2 8 ; sex : \ male 00 ]. This problem is solved in the IQL data model but leads to a more complex definition of the data model. Since it does not play any role in the rest of this paper we do not present the IQL-solution here but refer the interested reader to the IQL paper [2].

Equality and Subtyping
In this section we will give reasoning rules for deciding subtyping and equality. We assume a fixed schema S consisting of hC; type; isai that is sound. Under this schema a type 1 is a subtype of type 2 , written as 1 2 , if it holds for all instances hO;val;extiof schema S that [ ext . It is easy to see that 1 2 iff 1 2 and 2 1 . Therefore it will be sufficient to give the reasoning rules for subtyping only.
The reasoning rules we will give consist of two parts. The first part consists of rewrite rules that let us rewrite a type into a certain normal form. The second part consists of rules that determine whether two types in normal form are subtypes. We will begin with the rewrite rules that eliminate all the intersection-types within a type. The first set of these are those that are obvious from the interpretation of ;,^and _ as, respectively, the empty set, the intersection and the union: The second set of rewrite rules for intersection-types follows from the interpretation of basic types, set-types and tuple-types. Here we use the notation ( 1 _ : : : _ n ) and ( 1^: : : m ) for all those types that can be reduced to this by removing the brackets of, respectively, the union and the intersection-types.
: : : c n ) ; ( c 0 1 _ : : : _ c 0 k ) whenever fc 0 1 ; : : : ; c 0 k g is the non empty set of maximal common subclasses of c 1 ; : : : ; c 2 . A class is said to be a maximal common subclass of a set of classes if it is a common subclass and every strict superclass of the class is not a common subclass. where fh 1 ; : : : ; h p g = f f 1 ; : : : ; f n g [ f g 1 ; : : : ; g m g and k = i whenever h k = f i and h k 6 2 fg 1 ; : : : ; g m g , k = ( î j ) whenever h k = f i = g j , k = j whenever h k = g j and h k 6 2 ff 1 ; : : : ; f n g . (^) ; ; whenever and are of the form b, c, [a 1 : 1 ; : : : ; a n : n ] or f 1 g but not both of the same form.
5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 The rules INT1-INT10 will reduce any type to an equivalent type without intersection-types by applying them until no more rules apply. Proof: It is easy to verify that these rules are all sound and as long as there is an intersection-type left one of them will be applicable. Furthermore, they either remove the intersection-type entirely or push it one level down the parsing tree while leaving the entire height of the parsing tree the same.

2
It should be noted here that applying these rewrite rules may lead to an exponential growth of the size of the type. This is due to the rules INT2 and INT3 that can practically double the size of the type when applied. Even if the number of intersection-types is constant the growth may still be exponential.
When the rule INT5, INT7 or INT10 can be applied there are apparently some local inconsistencies in the type. For deciding whether the type as a whole is inconsistent i.e. it is empty, we additionally need the following pair of rewrite rules: Proof: The only-if part follows form the soundness of the rewrite rules. The if part can be easily proved by induction upon the structure of the type using the fact that a type without intersection-types can only be empty (under a sound schema) if it is either the empty type, a tuple-type with an empty field or a union-type consisting of two empty types.

2
Since the rewrite rules cause an exponential blow-up of the type this algorithm for deciding emptyness is also exponential. That it will be difficult to find an algorithm that is not exponential in time follows from the following theorem.

Theorem 3.3 Deciding whether a type is empty is co-NP-complete.
Proof: First we show that the problem is in co-NP by demonstrating that there is an NP algorithm for deciding the inverse problem. This algorithm consists off guessing a constituent of the type that is not empty. A constituent of a type is obtained by replacing all subexpressions of the form ( 1 _ 2 ) not nested in a set-type with either 1 or 2 . It holds that every type is equivalent with the union of its constituents. Thus a type is not empty iff one of its constituents is not empty. We can now reduce the part of the type that is not nested in a set-type with the INT and EM rules in polynomial time because the rules INT2 and INT3 can never become applicable. Because set-types are never empty (they always contain at least the empty set) it holds that the type is now reduced to ; iff it is empty. Therefore it is decidable in polynomial time whether a constituent is empty or not.
The hardness result is shown by reducing the problem of checking if a CNF formula is unsatisfiable, known to be co-NP-complete [8]. This can be done by translating the formula to a type that is empty iff is not satisfiable. For every variable x i in we choose a different field name f i . Then we transform by to a type by replacing every and every literal : If there is a value of type then it defines an assignment that satisfies by letting x i be true or false if the value of every field f i is, respectively, a tuple or a set. Conversely, we can transform any assignment that satisfies to a value that belongs to by letting every field f i be either the value [] or fg if x i is assigned to, respectively, true or false. Thus is empty iff is satisfiable. 2 The final rewrite rule splits tuple-types that have a union-type as the type of one of their fields. We say that if no one of the rules INT1-INT10, EM1, EM2 or SP applies to a type then it is in split normal form. It is easy to see that a type is in split normal form iff it contains no intersection-types, ; is not an argument of a union-type, and the type of a tuple field is neither ; nor a union-type. A type is in partial split normal form if this only holds for those parts of the type that are not nested inside a set-type. This normal form is interesting because a type in partial split normal form can not be split into two semantically strictly smaller types unless it is already a union-type.
5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 8gj9fi : fi = gj^i v j [f1 : 1; : : : ; f n : n ] v [ g 1 : 1 ; : : : ; g m : m ]  Although the rule SP is an extra source of exponential growth a type grows only single exponential when rewritten to split normal form. That it will be hard to find an algorithm for types without intersection-types that is not exponential in time is shown by the following theorem.

Theorem 3.6 Deciding whether is co-NP-complete.
Proof: Hardness is easy because ; iff ; which was proven co-NP-hard in Theorem 3.3.
We show that it is in co-NP by construction of a non-deterministic algorithm in polynomial time. The algorithm has to be both polynomial in the size of the schema and the types and . First it guesses a constituent and then it reduces intersection-types except those between classes and those nested in a set type. Then it applies INT6 to the largest possible intersections of classes not nested in a set-type and guesses a (sub)constituent by choosing one of the common subclasses. The now remaining intersections that are not nested in a set-type are all reducible to ;. This is because every such intersection is either between a class and another intersection or between a class and a type that is neither a class nor a union-type. Finally, empty types are removed using the EM rules. Note that iff every one of its (sub)constituents is a subtype of .
The type 0 that is now constructed is in partial split normal form. We can now use the rules of the v-relationship to determine if this type is a subtype of . If it is necessary for this procedure to decide whether 00 v 0 where 00 is a subexpression of 0 inside a set-type then we can repeat the same procedure for 00 .

2
Due to rule SP the algorithm even remains exponential if does not contain any intersection-types. It can, however, be shown that even this subproblem is already intractable.
5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 Theorem 3.7 Deciding whether where and contain no intersection types, is co-NP-hard.
Proof: This is shown by reducing the problem of checking if a CNF formula is unsatisfiable. We will construct the types and such that they are polynomial in the size of and that iff there is no assignment satisfying .
For the propositional variables x 1 ; : : : ; x n in the formula we construct the types 1 ; : : : ; 2 n as follows. Let g 1 ; : : : ; g m be distinct field names with m = log(2n), then i = [ g 1 : 1 ; : : : ; g m : m ] with j = [ ] if the j'th bit of the binary representation of i is 1, and j = f[]g if it is 0. Note that the semantics of all i 's are pairwise disjoint and that their size is logarithmic in the number of variables in .
The type is constructed as follows. Assume that the formula is of the form 1^: : : k . Then = [f 1 : 1 ; : : : ; f k : k ] with f 1 ; : : : ; f k distinct field names and where i is obtained from i by replacing the literals x i with i and :x i with i+n .
We construct as the union of all tuple-types with exactly fields f 1 ; : : : ; f k of which two fields contain i and i+n , respectively, for some x i and the other fields contain the type ( 1 _: : : _ 2 n ) . Note that the number of such tuple-types is nk(k 1) and that the size of is therefore polynomial in the size of .
If we assume that an assignment can assign a variable to both true and false then it holds that every constituent of corresponds with a certain assignment of the variables satisfying and vice versa. All the constituents of correspond with inconsistent assignments (i.e. some x i is bound to both true and false) and vice versa. So it is clear that is a subtype of iff all the assignments satisfying are inconsistent.

Sound Schemas
The soundness of a schema was defined as the property that no class may be empty in all instances of the schema. It is clear that this is a desirable property for a schema and that unsound schemas indicate a modeling error. Therefore a syntactical formulation of soundness is required so that it can be checked algorithmically. int], which is impossible. The value of an object of a certain class must always be of all the types of the superclasses (including the class itself). This is equivalent with saying that it should be of the type that is the intersection of the types of all the superclasses. This type is said to be the full type of that class. In the example above the full type of Secretary is ([birth date : str]^[name : str; address : str; birth date : int]). It is clear that if the full type of a class in a schema denotes the empty type then the schema is not sound. Since the reverse can also be shown to hold we obtain the following syntactical characterization of the soundness of a schema.

Theorem 4.1 A schema is sound iff no full type of any class in the schema is reduced to ; by the rules INT1-INT10, EM1 and EM2.
Proof: The only-if part follows from the soundness of the rules and the observation that the objects in a class must have a value that is of the full type of that class. The if-part is proved by the construction of an instance with for every class an object of that class i.e. this object belongs only to this class and its superclasses. In such an instance a type within the schema not reduced to ; by the rules 1-12 has a non-empty semantics. Therefore we can choose a value for every object in every class since the semantics of the full types is not empty.

2
Since our algorithm for deciding emptyness is exponential in time this will also hold for the algorithm deciding soundness. This remains even true if the types in the schema do not contain intersection-types and the number of classes 5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 remains constant. It is, however, also easy to see how the proof of Theorem 3.3 might be adapted to prove that checking soundness is co-NP-hard.
If there are no union-types in the schema then the algorithm is polynomial. This special case was already mentioned in [5] as solvable in polynomial time. On the other hand it is easy to see that deciding soundness is NP-complete because deciding emptyness of types is already co-NP-complete.
It is interesting to compare our work with that in [5] where soundness is stated to be EXPTIME-hard for a different kind of data model. The main difference between our and their data model is that they allow objects to belong arbitrarily to several classes at once. Furthermore, they limit the types of classes to the form [f 1 : f 1 g; : : : ; f n : f n g ] with i being a type formed of union-types, intersection-types, negation-types and classes. Negation-types are written as : and contain all the objects that are not of type . Also it is possible to specify a type such as i above as the superclass of a class. Finally, they allow to-and from-cardinalities to be specified with every field. We conjecture that the fact that objects can simultaneously belong to any set of classes explains the main difference in complexity.
If we limit the types in our data model in the same way but maintain that objects can only belong to several classes if they belong to some common subclass, the soundness becomes decidable in polynomial time. This follows from the fact that the emptyness of types consisting of union-types, intersection-types and classes can be decided in polynomial time by checking if there is some class that is a subtype of this type. If there is not such a class then the type is empty. Note that we did not add negation-types to our data model in this case. If we also want objects to be able to belong simultaneously to an arbitrary set of classes then we can simulate this by extending the schema with a class for every subset of the classes in the schema. Evidently this would cause the schema to grow exponentially.

Schemas with Bounded Types
In the previous section we presented an algorithm for detecting typing conflicts between subclasses and superclasses or between common superclasses. Sometimes, however, typing conflicts do not render the full type of a class completely empty. An example would be a class with two superclasses having, respectively, the types [a : (int _ null) and These examples demonstrate that when the full type or a field within the type is bounded i.e. has only a bounded number of values, then this might indicate a modeling error. Therefore we present an algorithm that determines the potential 2 cardinality of a type. This algorithm can also be used to check whether certain fields of tuples (as opposed to the complete type) are bounded. How this is done will be indicated later.
First we reduce the full type with the rules INT1-INT10 so it contains no more intersection-types. Then we determine its cardinality with the function de such that de gives the maximum cardinality of [ It is easy to see that this algorithm can become already exponential in its first step where the intersection-types are reduced. This is then even worsened by rule BT6. If, however, we only need to know whether the type is bounded then this rule can be simplified by omitting d 3 e and the total algorithm becomes single exponential.

Theorem 4.2 Deciding boundedness is co-NP-complete.
Proof: The hardness follows easy from Theorem 3.3 since the type [a : int; b : ] is bounded iff is empty.
We show that it is in co-NP by construction of a non-deterministic algorithm in polynomial time deciding the inverse problem, i.e., unboundedness. The algorithm has to be both polynomial in the size of the schema and the type. First it guesses a constituent and then it reduces intersection-types except those between classes and those nested in a set type. Then it applies INT6 to the largest possible intersections of classes not nested in a set-type and guesses a (sub)constituent by choosing one of the common subclasses. The now remaining intersections that are not nested in a set-type are all reducible to ;. This is because every such intersection is either between a class and another intersection or between a class and a type that is neither a class nor a union-type. Finally, empty types are removed using the EM rules. Note that is unbounded iff one of its (sub)constituents unbounded.
For deciding the boundedness of the obtained constituent we can now use rule BT5 and apply the same procedure recursively to the parts nested within set-types.

2
If the original type does not contain any union-types then the first step will also be polynomial and therefore also the total algorithm. If the original contains no intersection-types then it is easy to see that deciding boundedness is also polynomial since the first step will do nothing.
Instead of checking whether a whole type is bounded we also would like to check whether there are any fields in the type that are bounded. An obvious way to do this would be checking all the fields of the subexpressions that are tupletypes. This, however is too crude since the type ([a : null; b : int] _ [a : int; b : null]) would then be considered suspect while it does not really limit the value of either field a or b to a bounded number of values. Therefore we limit this approach to fields of tuple-types that are not arguments of union types. The tuple-types that are arguments of union-types are treated in the following way. For every field name f we look for the maximal subexpression of the form ([: : : f : 1 : : : ] _ : : : _ [ : : : f : n : : : ]) and determine whether ( 1 _ : : : _ n ) is bounded. In the example above this would amount to checking for field a whether d(null _ int)e = 1 and for field b whether d(int _ null)e = 1 .

Types with Redundant Options
The purpose of the type that is specified with a class in a schema is to give the specialization of the types of the superclasses. This type should ideally give only the extra restrictions to those that are already stated by the types of the superclasses. Moreover, it should not specify options that are already forbidden by these types. For instance, if the type of a superclass is [a : ( int _ bool)] and the type of the subclass is [a : ( str _ bool)] then the bool-option in the subclass is superfluous and indicates a modeling error. A more complicated example would be the schema hC; type; isai The type of International Flight allows the load to be a mixture of persons and goods. The type of superclass Flight, however, allows only loads that consist either of only persons or only goods. The type of the field load in the subclass may therefore be considered somewhat misleading; it seems to imply that international flights can carry mixed loads. It would have been better if the field load was not specified in the type of International Flight at all. Informally, we would like it to hold for the type of a class that all the values of that type that have only the specified fields can be extended to a value that belongs to the types of the superclass by only adding extra fields. This constraint captures the intuition that if a certain type is specied for a certain field then that field should be able to become all the values of that type and not just a smaller subset. It is clear that the example above does not fulfill the condition because Notice that the fact that we only consider specified fields is important because otherwise the constraint would amount to demanding that the type of a class is a subtype of the types of the superclasses. This would make it necessary for the modeler to specify explicitly the full type with every class. Before we proceed with the formal definition of a proper schema we will formally define what it means for a value to be of a certain type and have only the specified fields. The set of these values is called the minimal semantics of a type and is given by the function [ We now define a proper schema as a schema for which it holds for every class that all the minimal values of the type of that class can be extended to a value that is of all the types of the superclasses by only adding extra fields. On the level of individual types we say that type is a proper extension of type , written as , if all the minimal values of can be extended to a value of by adding extra fields. It may be clear that a value can be extended to a value that is of the types 1 ; : : : ; k iff it can be extended to a value of the type ( 1 _ : : : _ k ) . Therefore a schema is proper iff it holds for all classes with type and 1 ; : : : ; k as the types of the superclasses (not including the type of the class itself) that ( 1 _ : : : _ k ) .
Deciding whether it holds that can be done by reducing to split normal form with rules INT1-INT10, EM1, EM2 and SP and then using the binary relationship between types defined by the rules in Figure 3.

Theorem 4.3 For every type and with in split normal form in this schema in split normal form it holds that iff .
Proof: The soundness of the rules is easily verified and holds even for types not in split normal form. The completeness is proved by showing firstly that if then they are in the form of one of the conclusions of the rules, and secondly that in all the rules the conditions are necessary conditions except for rule PR8 where the condition is only necessary if is not a union-type and in split normal form. Note that if none of the rule PR7 is applicable then the left type is not a union-type.

2
The complexity of this algorithm is similar to the one we introduced for deciding subtyping. Furthermore, the problem can in mostly the same way as for subtyping be proved to be co-NP-complete.

Conclusions
We have discussed the problems of reasoning about equality and subtyping in IQL-like schemas containing union-types and intersection-types. It was shown that these problems are co-NP-complete but that there are relatively simple sets of rules that can be used to decide them. The presented rules are similar to those presented in [3] where it is shown how a sound and complete subtyping algorithm for union types can be obtained out of some algorithm for intersection types. The main differences with our work is that we do not allow general functional types but only tuple-types and that we have set-types and classes as types.
We used these rules to detect inconsistent schemas and showed that this problem is also co-NP-complete. These results are comparable to those in [5] where the same problem was studied for schemas that allowed objects to belong simultaneously to an arbitrary set of classes but limited their values to relatively simple tuples. Finally, we also have used the reasoning rules as a starting point for algorithms detecting situations in schemas that might indicate a modeling error.