Unformatted text preview: dundant, and every node will be satis able in the sense that some instance will assign a nonempty active domain to that node. Furthermore, we require that the intended type of an object in the hierarchy be type con ict safe after inheritance. By that we mean that, con ict free structure of an object/class should be guaranteed if necessary by using the method of withdrawal. Derived schema components are one of the fundamental mechanisms in semantic models for data abstraction and encapsulation. Such a component has two elements: 30 F16 fighter aircraft boats helicoptergunship someobject (a) (b) Figure 3: ISA restrictions. a structural speci cation and a derivation rule. It thus allows to incorporate dynamic information directly into the database schema. Known semantic models only allow derived subtypes and attributes. In OR model we impose no restriction on the type of derived schema components. That is all permissible components may be derived. Derived components are readily identi able in an OR schema. Such components are represented using dashed symbols. The horizontal line in each component separates the structural speci cation and the derivation rule the derivation rules are speci ed in the lower half of the symbol. The rule part may also contain constraints relevant to that component. The language for the derivation rule in OR model is rst-order predicate calculus. In the next section we introduce the notion of legal access which imposes a set of restrictions on the dynamic components of the database. 2.5 Accessibility
In the OR model the only way to reference the properties of the objects is by invoking the attributes/methods using messages. The set of methods that are visible from outside the objects are the only ones that can be invoked. There can be methods in objects and relationships which are private to them, and thus are invisible from the interface. Also, not all methods that are visible through the interface are always available. We require that only relevant methods can be invoked. A method is relevant if the objects or relationships involved are related. Two classes/objects are related if they are involved in a hierarchy association, a relationship association, or an aggregation association. For example, the object class B100 or its instances are related to DC10-30 through hierarchy association (but not to the speci c instances of 31 DC10-30). The class B100 is related to seat through relationship association useseat. The attribute engine in DC10-30 is of type rollsroyce (aggregation), hence DC10-30 and rollsroyce are related. The related objects or relationships are allowed to refer to the public properties of each other, and such accesses are called legal accesses. The notion of legal access is thus in uenced by the notions of non-monotonic inheritance, associations and encapsulation. 2.6 Update Semantics
In this section we will investigate the issue of update semantics in OR model. The semantics is very intuitive, and we will take a very simplistic approach to describe it. There can be several forms of updates, namely change in attribute values, change in object schemas or types, change in method implementations, change in class memberships, change in relationships among objects, change in constraints, change in inheritance, addition/deletion of objects and classes, etc. Each of these changes has consequences in the OR schema. We will explain them very brie y. Change in attribute values are permitted if the value refers to a basic value, or an existing database object at any time without any restriction. In some models (e.g. Orion) composite objects have a ownership relation. For example, if object cathy has an attribute called doctor with a value john meaning the object identi ed by the id john is the family doctor of cathy, then it is regarded that cathy owns object john. This is called a dependency relationship. In models like Orion, this dependency means that if the object cathy is deleted, then the object john must also be deleted. In OR model we do not insist on this dependency relationship. Hence if the attribute value is changed, or the so called owner object is deleted, the owned object will continue to persist in the database. This is also because of the view we take with respect to the uniformity of the class and instance duality of objects discussed earlier. If we incorporate the notion of dependency relationship in our model, then unwanted results may happen. For example, if the owned object is removed then it is possible that all the instances and subclasses of the object has to be removed due to type safety requirements discussed earlier (since we allow arbitrary subtyping). If some other objects have references to any of the instance objects that are removed then they will become dangling and result in an \inadmissible" database. 32 However, if it is so desired, such dependency relationship may be implemented via a suitable constraint speci cation. This approach gives us...
View Full Document