Re introduction is a mechanism for inheriting 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: from the ancestor DC10-30 is reintroduced as the communication instrument in place of the costly radar system. Since an object class can be a subclass of multiple superclasses, multiple inheritance is possible. In that event the subclass inherits properties from all its superclasses in a way described above. 24 The notion of non-monotonic inheritance is not captured in any of the contemporary SDMs. However in OO data models only overriding is supported. Withdrawal is handy in models like F-logic, OR model, etc. where there is no distinction between class attributes and instance attributes and classes and instances have no apparent distinctions. Consider for example, the attribute averageprice in DC10-30. This is meant to be a class property and does not make any sense in an instance object of the class DC10-30. We have two choices { we may withdraw this method in DC10-30 by blocking it, or we may withdraw it in each instance by inhibiting the method as described earlier. SDM on the other hand can handle this situation nicely by de ning the attribute averageprice as a class attribute and hence no instance will share it. However, now a subclass in SDM has to rede ne the same attribute if it needs it. In OR model, a new de nition is not necessary in a subclass in a similar situation, and can be nicely modeled using withdrawal. Note that the notion of withdrawal is unique to OR model. Withdrawal is also useful to resolve schema con icts in case of multiple inheritance. In our example of Figure 1, in absence of withdrawal, MD10A would have inherited cockpit : mitshubishi from MD10 and cockpit : bombardier from cargoaircraft, resulting in a clear con ict of types. To resolve the crisis in our example, object MD10A favors the signature cockpit : bombardier from cargoaircraft by selectively inhibiting the inheritance of signature cockpit : mitshubishi from MD10. This is a major problem in a dynamically evolving database where schema and class membership is constantly changing, and OR model can handle this kind of situation nicely. 2.3.10 Inheritance Con ict Resolution Since we allow objects to be modeled as a subclass or instance of multiple superclasses, inheritance con icts may arise as discussed above. OR model incorporates a simple con ict resolution rule to handle such con icts by avoiding inconsistent schema design. The rst rule is, inheritance is allowed from a unique source (the point of de nition) in the SG hierarchy. If this condition is violated, inheritance of the property in con ict is automatically inhibited in the class where it is in con ict. By de ning suitable inhibition and/or blocking of properties, the designers may resolve this con ict by ensuring a unique source for the property. Hence, OR model supports two modes of con ict resolution { (i) user speci ed con ict resolution, and (ii) automatic or default 25 con ict resolution. 2.3.11 Encapsulation In the OR model the implementation of all the intensional attributes, or methods, is private to the object/class or to the relationships where they are de ned. Users only see the interface to the objects or relationships, through which the set of methods applicable, as well as their signatures, are visible. It is possible to de ne some attributes or methods to be private to the object/class or relationship. Private attributes and methods are not visible from outside, and are only accessible by the object/class or the relationship in which they are de ned, for the implementation of other methods in it. This provides a limited form of security addressed in some research works 12]. The concept of providing an interface to objects and relationships through which all legal methods are visible, and of localizing the implementation of the methods to the objects or relationships, is known as encapsulation. Encapsulation enhances implementation independence, modularity, and abstraction. In our example, the attributes computer, weapons and bombs are private to the class strategicbomber and are not visible from outside. Suppose the method weapons makes use of the attribute airforce to decide the set of weapons and bombs that the aircraft will carry. The methods bomberunit and weapontransport in B100 then use the methods weapons, bombs and missileunits to decide the kind of bomb transport and launching system to be installed in the aircraft. Here the methods weapons, bomberunit and weapontransport use several private methods to respond to a message. Although these attributes and methods are inheritable, no other object or relationship can access these methods except via inheritance. Notice that the notion of encapsulation in OR model is somewhat di erent than in semantic models and OO models. Essentially, SDMs encapsulate structural aspects of objects, whereas OO models encapsulate behavioral aspects of objects which are the method implementations. OR model extends the notion of encapsulation of structural aspects of objects by allowing private attributes and methods that are invisibl...
View Full Document

This document was uploaded on 01/10/2011.

Ask a homework question - tutors are online