E one outward solid arrow and the solid arrow from a

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: ned in aircraft. Note that the same attribute tseat is represented in Figure 1 using an attribute in aircraft with arguments of type classcategory and a range type of integer. Again consider the attribute reeqp of Figure 1. To represent a multi-typed range 18 we introduce a multi-type constructor, again derived from standard SDMs, as shown in Figure 2 (d) (a triangle inside a circle). Each child of these nodes must be of abstract object types (triangles) for the reasons described earlier, and such nodes may only be used in the range of an attribute or a grouping type. In some models (e.g. 5]) attributes are not allowed to have objects as values (i.e., the range of the attribute function may not be an abstract type), and others do not allow arguments in attributes (e.g. 5, 36]). This limits the application of these models, weakens their modeling capability considerably, and parametric methods become impossible to capture. In the former case, the model lacks the strength of supporting complex objects that is the main purpose of OO models and in the latter case the methods become essentially an attribute computed only at run time. 2.3.5 Signatures As discussed before, all attributes and methods (function) in an object have a type. A type of an attribute speci es what type of value an attribute can take. A type associated with a method, also called a signature, is a tuple of the types of its input arguments and the type of the computed value, of the form 1 : : : n ! t. The types associated with the method tseat in aircraft are aircraft!integer, and aircraft classcategory!integer, where aircraft is the type of the context and is implicit, classcategory is the explicit input argument type, and integer is the type of the output value. Note that OR model allows multi-typing of methods and in this example the same method has two distinct signatures. This is essential for supporting method polymorphism described later. When a method tseat is invoked, which method type will be activated will now depend on the speci cation of the message. The type of an abstract object is, however, composed of its constituent property types { attribute and method types. Hence the type of the object aircraft is <company : string, tseat : integer, tseat(classcategory) : integer, range : integer, kitchens : integer, engines : integer, cockpit : mitshubishi>. 19 2.3.6 Classes and Instances In OR model, objects (entities) are grouped into classes and classes are organized in a specialization-generalization (SG) hierarchy3. In the spirit of the extended ER model, this leads to specialization (in most of the cases) where the classes lower in the SG hierarchy inherit the properties of those higher up. In our example of Figure 1, class DC10-30 is a specialization of the class aircraft. Class DC10-30 has all the properties4 of the class aircraft, and some more. Classes have objects as their instances, which may have specialized properties. The SG hierarchy naturally induces (super)class/subclass associations among classes. For example, with respect to class DC10-30, aircraft is a superclass and MD10 is a subclass. It is possible for an object class or an object to be part of multiple (super)classes at the same time, if it shares properties with each of these classes. In our example class MD10A is a subclass of the classes cargoaircraft and MD10. Note that in OR model we do not incorporate the object type called free 2], since we do not impose the restriction that a superclass has to be de ned before a subclass (free) is de ned, nor do we require that all the subclasses should be removed from the database when a base class or the highest class is removed. In OR model each class has its own existence. But we do require that a class should be well typed or well structured. By well typing we mean that if an object has a property, it must have a signature. Alternately an object can not have properties without a structure. We, however, do not distinguish between class objects and an instance objects. An instance object may be viewed as a (sub)class object, if it has some new properties compared to its (super)class, some properties are withdrawn (described next) or it has its own instances. This view point has advantages with respect to a logic based query language design for the model, and with respect to the update semantics that we will discuss later. This is also because of the reason that the object hierarchy in OR model is not based on type inclusion semantics. This view point is justi ed because the objects in semantic models are abstract anyway that is their types are distinct We do not distinguish between specialization and generalization as in other semantic models (e.g., IFO 2], SDM etc). Also note that the hierarchy is not based on the sub-type relationships as it is in most of the OO and semantic models where a subclass inherits its superclass' structure and properties, and thus has a superset of properties of all its superclasses. The class hierarchy is de ned by the user and is decided by the application need. This gives OR model a de nite advantage over other models whic...
View Full Document

Ask a homework question - tutors are online