The class hierarchy is de ned by the user and is

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: h we will discuss later in the section on update semantics. 4 In this particular instance. 3 20 from their attributes and sub- or supertypes 39], and their relationships with other objects in the database, and their identity does not depend on their attribute values or types. This uniform view point of classes and instances can be justi ed from yet another perspective and we will take up this issue again in the next section and when we discuss inheritance. 2.3.7 Inter-object Associations In the OR model, inter object associations or relationships are of three kinds, namely { aggregation, hierarchy, and relationship associations. Aggregation association results when objects (oids) are used as values (in the range) of attributes or methods, thereby forming an attribute to object association. Since the method has the handle on the object through its id, it can now refer to its properties, and those properties may arbitrarily refer to properties of other objects in turn, which are essentially aggregations of properties. Using aggregation association, it is possible to have nested data structures of any depth, even recursive structures. This is the counterpart of the composite objects in OO data models. In a later section we will see that the update semantics of composite objects in the OR model is very di erent from that of those in many OO models. An instance of aggregation in our example is refuelsys in the class B100 which refers to an object shell8 of constructed type shell (for want of space, the type shell and its instance shell8 are not shown in Figure 1). The second kind of association is the hierarchy or is-a association between objects and classes, and between two classes, resulting from the SG hierarchy. Recall that the SG hierarchy in OR model is somewhat di erent from the hierarchy de nition in other SDMs. We allow only one kind of is-a association and we do not incorporate the generalization or exclusive subclass 73, 36] is-a in OR model. It is however possible to capture these notions in OR model by specifying a constraint in the schema that says that the domain of each of the subclasses of a generalized class is disjoint. This will then imply that no multiple subclass relationships are possible among the classes under the generalized class. The OR subclass relationship is based on a common set5 of attributes that the objects share among the classes rather than a subsetsuperset relationship of attributes as required by many semantic and OO models. Loosely speaking. In some cases the intersection may be empty. This kind of situation in real life is very unlikely to happen, which however may be attributed to as ill structured hierarchy or as a consequence of bad schema design. 5 21 This, surprisingly, is consistent with the SDM approach 36] in which classes can have special attributes and these attributes are not inherited down the SG hierarchy. That is class attributes are local to a class and are not shared by any subclass or instance. Thus we may view the sets of attributes that are not common to pairs of classes as class attributes. Note that we do not distinguish between class attributes and member attributes. To avoid inheritance of unwanted attributes (e.g. class attributes), we resort to a notion called withdrawal (described next). However, the set of instances in the superclass is a super set of the set of instances in the subclass6. The third kind of association is the relationship association among classes of objects (or entities). Relationships among classes of objects may be n-ary in general. We contend that relationships have a character distinct from classes of objects and are aggregations of constructed types. Thus they are relations involving di erent classes of objects, and do not participate in any SG hierarchy. As in the relational model, the objects in the participating classes form the key of the relation. Relationships can be one-one, one-many, or many-many. This is called the maximum cardinality of the relationship. In our example in Figure 1, useseat is a 3-ary relationship involving the classes aircraft, seat and classcategory, which says that an aircraft uses a type of seat in possibly more than one accommodation class ( rst class, club class, etc.). Relationships may have minimum cardinalities too. A minimum cardinality is shown by a hash mark on the side of the participating object class. A minimum cardinality speci es whether the objects of the class are required to take part in the relationships or not. 2.3.8 Methods in Relationships Many OO models do not support relationships (or aggregations) as a rst class component, and most of the models which do, do not support methods in the relationships. In the OR model, relationships may have descriptive attributes/methods in exactly the same way as objects. The only di erence is that in the case of methods of objects, the context is the object (or the class) and the type of the object/object class takes part in the signature of the method. In the case of relationships, the context is the key of the relationship and, hence, the type of this key takes part in the method This means that if...
View Full Document

This document was uploaded on 01/10/2011.

Ask a homework question - tutors are online