Since the underlying concept is value based it also

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: s of the DK model. The OBJECTModeler presented in 27] attempts to capture user's view of the data and takes an OO approach. Similar to ER model, it emphasizes on type constructors instead of attributes and functions. It uses aggregation and grouping as the abstraction mechanism. However, it does not capture the true spirit of OO modeling and the idea of object based entities. That is the underlying model is still value based. It somehow comes close to the spirit of network data model. Although it allows multi-valued attributes, it fails to capture data relationships in such attributes (m-m relationships). Other shortcomings include the dynamic schema components, parametric attributes, and other several OO features. In 35], Object Behavior diagrams are proposed to model objects and their behaviors and mostly concerns itself with behavior speci cation of object models. The schema representation in this model seems to su er from similar draw backs as it was in the case with OBJECTModeler. Overall, the model seems complex, and description of methods and its associated behavior seems to have no clear mapping. The model proposed in 5] is heavily biased towards OO modeling, and concerns mostly with constraint management, and so does 34]. We do not consider them as general modeling tools since they do not capture several essential features we deem necessary for an abstract database model. But they do introduce a rich set of constraint speci cation and maintenance tools. The CASE based model proposed in 17] is a semantic network based model developed speci cally for the OO language O2 53] and Morse. It has limitations, in our opinion, even as an OO modeling tool. It is an example of DBMS dependent data model. It also proposes an automated design procedure of OO database schema from abstract speci cations of the models. To model a wide range of future applications such as engineering design, biological and geographic database, etc. a generalization of several data modeling tools that are currently available is required. The model should also be capable of providing support for modular schema design, and as an aside, should support schema evolution in a 8 natural way. The experience with semantic and object-oriented data modeling and the needs for future database modeling applications suggests that an abstract data model should particularly possess the following properties: (i) it should be simple, expressive and versatile, (ii) should serve as a schema speci cation, documentation and communication tool among various levels of users, (iii) it should be able to capture user's view of the enterprise data, (iv) it should naturally support a user-friendly graphical user interface for schema description and query processing, (v) it should have a simple but rich set of high level abstraction mechanisms, (vi) it should be able to model abstract data types, inter-object relationships and their associated constraints, (vii) encapsulation should include both the behavioral and structural aspect of data, (viii) the model should emphasize on type constructors rather than attributes for modeling inter-object relationships, (ix) should allow value as well as and id based objects, etc. The semantic models in their present form are capable of capturing structural encapsulation, notions of abstract objects, derived schema components, type constructors e.g., set objects, relationships, complex objects, etc.), is-a hierarchy of object classes, several forms of constraints, etc. The OO models on the other hand, support objects of abstract types, and classes, methods. messages, object hierarchy, (non)monotonic and multiple inheritance, behavioral encapsulation, etc. OO models also incorporate a number of constraints similar to update constraints which are unique to OO models (e.g. update dependency relationships). The similarity in the set of concepts in these two class of models suggest that an integration of this two concepts is possible. In the next sections, we present our OR model. We start by de ning the goals of this model that includes a balanced mix of the features available in SDMs and OO models. It also incorporates a limited form of security features 12] in the form of privatization of methods and attributes and the notion of legal access to objects and methods. 2.2 Objectives of the OR Model We extend the concepts of the current SDMs in the direction of OO paradigm to facilitate modeling of taxonomical and hierarchical data that are encapsulated with operations, and thus enrich SDMs with modeling features available in the OO paradigm. 9 We incorporate the notions of objects (de ned shortly), entities and relationships (in extended ER sense), and values in our model as basic building blocks. We stress type constructor based inter object associations (as in extended ER models) { called relationships as opposed to attribute based associations (as in FDM) { called inversions 36]. We extend the framework of inheritance in OO models by introducing the noti...
View Full Document

This document was uploaded on 01/10/2011.

Ask a homework question - tutors are online