233 domains and values in the or model there are two

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: essentially basic objects and are atomic elements of the corresponding basic domains such as integer, real, string, etc. Many of the existing OO models (e.g., see O2 model 53] and F-logic 47]) treat basic values also as objects, some models (e.g., O2) even allow oids for basic values. We believe this is unnatural and make a clear distinction between them. Basic values are just values, distinct from other objects, without any surrogates or ids, and are naturally treated as just values. Unlike objects they do not participate in any class hierarchy (described next). On the other hand, abstract objects (their surrogates or ids) are values of constructed types. Thus, the value that can be associated with an attribute may be basic, or structured. For example, the value of engines in aircraft is basic, the value of the 14 attribute weapons in the object strategicbomber is set structured, the value of engine in DC10-30 refers to another object of type rollsroyce and thus is of constructed type, while the attribute reeqp in object md10 is of multi-type constructed value. That means each of the values of the attribute reeqp belongs simultaneously to the types type1 and heavyduty. 2.3.4 Attributes and Methods Objects (except basic objects) are described using attributes which are essentially named data items describing the properties of an object. For example, in Figure 1, company in aircraft, and takeo en in DC10-30 are attributes. There are two kinds of attributes in the OR model. The kind of attributes that store data explicitly in the database are known as extensional. Intensional attributes have a procedure associated with them in order to compute the value of the attribute at run time. The language of implementation of intensional attributes in OR model is a rule based language (e.g., rst-order logic or predicate calculus) which has a clear syntax and formal semantics. For example, in the object class aircraft, company is an extensional attribute, while tseat is an intensional attribute. The latter represents the total number of seats in an aircraft. This is dependent on the oor space left after placing the kitchens in the aircraft and on the type of seats that are being used in di erent accommodation classes in the aircraft. Since the values of intensional attributes are computed using a procedure, in terms of functionality they capture the concept of methods in OO models and the derived schema components (derived attributes) in SDMs. Methods have an underlying context, which is the object where they are operative, and a set of typed input arguments. Thus, a message should have a matching context and a set of arguments in order to be accepted by a method. An accepted message leads to a successful invocation of a method (procedure). The implementation of a method is hidden in the object where it is de ned. E.g., tseat is a method in the object class aircraft. In OR model it is not required that an attribute name be unique in a family of classes as it is essential in some of the models (e.g., 36]). This allows OR model to capture the notion of method polymorphism that almost all the OO models have. We, however in general, do require that the signature (described shortly) of each method be unique in a family of classes that are related via inheritance or is-a association. The value of an attribute may be null, a basic value, a constructed value, 15 or a multi-typed value. An attribute can be either single valued or set valued. Speaking di erently, attributes are the means of relating two or more types of objects. Hence, an attribute in the OR model is viewed as an n-argument partial function from an n;tuple of types to another type, where n 1. The object in which the attribute is being de ned is called the context and acts as the rst argument of the n argument function. Unlike other semantic models, we impose a type restriction on the domain and range types of these attribute functions. We allow only basic and constructed types in the domain, and all but aggregation type are allowed in the range. The function may be single valued or set valued. SDM supports a feature called type attribute which is an attribute associated with grouping type that keeps a kind of count, or other statistics, on the grouping types (e.g., cardinality of the set). We do not support this feature because we support other feature that may augment the functionality of type attributes. We also do not anticipate any natural use for such feature in our framework. Moreover, we do not allow grouping type database objects in isolation other than as a value of attributes and methods. As mentioned above, all attribute functions are said to have a type. The type of an attribute function f is of the form 1 : : : k ! t if it is single valued, or !f 1 ::: k ! tg if it is set valued. If the function is single valued, then each tuple in the domain is assigned exactly one object in the range of the expected type, otherwise it is assigned a set of objects from the active domain of the range type. It is also possible to assign a type to f of the form 1 : : : k ! ft1 : : : tmg, where it means that f is single valued but the obje...
View Full Document

Ask a homework question - tutors are online