2314 virtual objects and relationships an object in

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: properties) may also be derived. Such an object is not stored in the database. Only the rule that describes how to derive the object is stored. Constraints may be speci ed on such objects. All the properties that might be needed to describe the object are derived from other database contents. Since these objects are virtual, 28 all their properties are also virtual. SDM supports virtual objects in the form of derived schema components, but requires that the objects be of type free (discussed earlier). We do not impose any such restrictions. Virtual objects may be used to model user views of the database using classi cation and association 19]. Classi cation is a form of abstraction in which a collection of objects is considered a higher level object class, and association is a relationship between member objects that is considered as a higher level set object. OR model captures these abstractions through an attribute of the virtual object in the former case, and by populating a set of pertinent objects as the member of the virtual object (class) in the latter case. Populating a virtual object (class) is a process that identi es the set of instances of the class and require some rule evaluation. The set of instance objects in the population may be ground or virtual. Except the fact that the virtual object is derived, it has no distinction with a stored object. Such an object will be only created using the rule when some reference is made to it, and will be removed from the database after the reference is completed. Similar to virtual objects, virtual relationships are also possible. The associations between objects may now be derived at run time. Pumping in the tuples of a virtual relationship will also require a rule evaluation which will derive the associations between objects. It is also similar in every respect with the usual relationships. If in a relationship, at least one of the participating object (class) is virtual and the object participates in the key of the relationship, then the relationship must also be virtual. 2.4 Global considerations In a broader perspective, we now discuss how we develop database schemes from the local constructs and building blocks described in the previous section. First we see the structural nature of OR schemas, that is we discuss how constructs can be meaningfully combined to form database schemas. Then we investigate dynamic aspects of the schema and consistency issues. We have already speci ed some of the restrictions we impose on the local constructs of the OR model. We restate several of them in this section from global perspective. Such restrictions are motivated by the underlying philosophy of the model and its objectives. We require that grouping objects be only used in attribute ranges because such 29 objects are rarely of interest in isolation. Note that some models (e.g., IFO, SDM, O2, etc.) allows such objects in the database to exist. We also do not allow aggregation or grouping type objects in attribute domains, and aggregation type objects in attribute ranges. Unlike IFO, SDM and O2, we do not allow complex objects in the attribute range, we use values in the range instead. Recall that a value may be basic or an object id which represents an id based object. Although the underlying structure of an object remains arbitrarily complex, the immediate structure is simple and is only one level deep. This approach is close to the spirit of O2 model. Note that aggregation association is only de ned for id based objects, not for value based objects. That means, the navigation in value based objects are similar to relational model. We also require that all the types mentioned in all the attribute domain and ranges are database objects except the basic types and grouping types. The restrictions on ISA constructs are simple. Though it is not required all the time, it is in general assumed that the database objects will be de ned top-down. That is certain base types will be de ned rst and then its subclasses, and so on. We also require that the ISA relations be acyclic. Consider the ISA de nition in Figure 3 (a). The three classes form a cycle and intuitively implies that the types are redundant, that is in every instance, the three types will contain the same set of objects. Furthermore, none of them can be considered as the base type and hence the underlying type of each of the objects are not deterministic. The de nition of Figure 3 (b) is also not allowed if it is assumed that the domains of the superclass objects aircraft and boat are disjoint. However, if someobject is an amphibian aircraft, we might want to lift the domain disjointness restriction and allow the de nition. Value based objects (entities) and id based objects (semantic objects) can not be mixed in a subclass relationship. That is an entity class can not be a sub- or superclass of an id based object class. If these restrictions are satis ed, it can be shown that every node will have an unambiguous underlying type, no pair of nodes will be re...
View Full Document

Ask a homework question - tutors are online