We extend the framework of inheritance in oo models

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: on of withdrawal which allows us to model several applications very naturally that we could not model using current approaches. We adopt in our model a subclass instance relationship scheme di erent from many others. In principle we do not organize classes of objects on the basis of their types, rather on the basis of the semantic relationships of the classes as viewed by the user (user de ned subclass relationships). This is consistent with the applications in the OO domains { such as engineering design, and biological databases, etc. This idea has its roots in the de nition of SDM classes. The existing notion of derived schema components in SDMs is extended to incorporate the notion of methods and messages in OO paradigm. The notion of encapsulation is also incorporated in our model, and we give a clear de nition of this notion in the context of abstract modeling. The notion of constraints in SDMs is extended by organizing them in strata (global, local, and inherited) that gives us a clearer semantic meaning of constraints. This also buys us the power of resolving constraint con icts, easier constraint enforcement and maintenance schemes. Finally, it is our intention to make the model expressive with a rich set of constructs, constraints and knowledge modeling tools while keeping it simple and easy to use. We take a diagrammatic approach to support a user-friendly schema design interface with a small number of constructs. We view our model as a documentation and communication tool among people in an enterprise at di erent levels. We also believe that our model is also capable of capturing user view of the data(base). Due to this uniformity it eliminates the need for a mapping from the user view of the data to the corresponding conceptual view. 2.3 Basic Constructs In this section we describe the basic constructs we use in our model and give their local semantics. In the next section we will then impose restrictions on the use of 10 these constructs as well as de ne their global semantics to be able to design meaningful database schema. Figure 1 shows a partial McDonnell Douglas Aircraft Design Database schema using OR-diagrams. The features in the OR model are represented using OR-diagrams, which play a role analogous to that played by ER-diagrams for the ER model. The legends in Figure 1 shows the meanings of each of the symbols used in the OR example. 2.3.1 Objects An object is a distinct real world entity with a unique identity. All objects have intrinsic characterizing properties. Properties of an object help distinguish the object from other objects. An object may be concrete or abstract. An object is concrete if the object can be described solely by its own intrinsic properties. These objects are the so called printable objects in many semantic models and are strings of alphanumeric characters. In OR model these objects are called the basic objects. Abstract objects on the other hand, are entities that are characterized by properties described using other basic or abstract objects. A notable distinction is that such an object is almost always an abstraction of the corresponding real world entity and is thus incomplete, while it possibly represents the object adequately for modeling purposes. Hence an abstract object can be viewed as a collection of representative properties of the real world counterpart. For example, aircraft and seat are abstract objects (types). Note that, in OR model a rectangle is used to denote an abstract object. The name of the object is written inside the rectangle above the horizontal line. Shortly we will see other types of objects. We say that an object is value based if a change in properties changes its identity. In OR model we call them entity. On the other hand an object is identity based or object based if its identity is independent of its properties. Such objects are actually identi ed by a surrogate, called an object id or oid. We call them semantic objects. In most of the semantic models and object oriented models, it is one or the other types of objects that are allowed - i.e., the entities or the semantic objects. In OR model, we allow a free mixing of both kinds of objects, and will make no distinction between them unless it is necessary. This uniformity in the OR model, gives us the capability of modeling heterogeneous databases, and design applications that require multi-model database integration. 11 tseat(classcat):integer engines : integer maxtilt : real facility : {string} legspace : real extensional attribute company : string class : string range : integer tseat : integer tseat : integer seat space : real type part rule/constraint part intensional attribute/method name part extensional rule / constraint part kitchens : integer aircraft useseat object classcategory intensional object attribute/method cockpit:mitshubishi section : string averageprice : real cost : integer reintroduction fireeqp : {{type1, heavyduty}} attribute/method inhibition takeofflen:integer usebody DC10-30 radio : string section : string attribute/method blocking relationship symbol gspeed : integer cockpit : bombardier radar : comsat usekitch floor(string):real name rule part radio : string fuel : grade1 intensional relationship symbol facility : {string} many-many relationship or MD10 kitchens : integer engine:rollsroyce object to private Figure 1: Partial McDonnell Douglas Aircraft Design Database Scheme. cargocap : integer body wing : highwing MD10.cockpit:mitsh...
View Full Document

Ask a homework question - tutors are online