sign in sign up
<<
Home , Data model, Data model (GIS)

The Integrated Model: A Perspective

David Beech and J. Samuel Feldman

Computer Research Center, Hewlett-Packard Company Palo Alto, California 94394, USA

Abstract fundamental to each discipline. Database systems are explicit about this, but in fact The integrated Data Model integrates every and every artificial concepts from three disciplines: intelligence system also embodies a . database systems, artificial intelligence, and We propose that a single data model can combine programming languages. Key concepts are the best aspects of all three disciplines and those of abstract type (allowing multiple remove many of the shortcomings of each. implementations), object (possibly having multiple types), and relation (definable by 1 .l Storing New and Different Types of Data logical formulas). This paper provides a brief overview of the model from a database Current database systems each support their perspective. own static set of built-in datatypes. Although work is continuing on extending the implementations of these systems so that 1. INTRODUCTION “unformatted” data may be stored, such measures are essentially patches. The Integrated Data Model (IDM) provides a more general and flexible foundation for the One important consequence of our application of manipulation of information than models recent programming language ideas to underlying traditional database management is that new datatypes can be defined as needed, systems. The facilities provided by the model and values of these types may be stored in the can be employed not only for database queries, database in the same way as other kinds of e updates, and report generation, but also for data. This is accomplished in our design by managing the arbitrary data structures used by our treatment of datatypes as abstract objects, systems programs and application programs. which provides a formal framework for defining Moreover, because this occurs in a database and using new types dynamically. Another way setting, the ability to share this information of looking at this capability is that programs concurrently with other users and to distribute may use the same kinds of data structures for information among different sites is provided in persistent data as for temporary data. the same way as for the more conventional kinds of data routinely stored in databases. 1.2 Natural User Interfaces

IDM takes data abstraction as the fundamental The intent of the design is to provide a model underlying idea, and draws together some that corresponds naturally to the way we concepts previously employed for database perceive information, while still providing systems, artificial intelligence applications, and sufficient power and allowing for efficient programming languages. A data model is access. We accomplish this partially with a form of entity-relationship model [Childs 88; Abrial 74; Chen 761. Models of this genre are increasingly being employed for user interfaces and tools [Dahl & Bubenko 82; Olle et d. 82; Wong t Kuo 821, because of their suitability for representing the user’s . Attempts to extend the to introduce an entity concept seem awkward [Codd 791. (We have in fact designed an English-like database manipulation language for our model as one example of a natural user interface.)

302 2. OBJECTS AND TYPES l Everything in an IDM database is an object. The central, pervasive concept in IDM is that of the object. Everything in an IDM database is l Each object is an instance of one or more an object; even the database is itself an object. types. The simple data abstraction idea is extended in two significant ways: l Each type defines the operations that are available for its instances. l An object may have more than one type.

l The only action available in IDM is to l An object may gain and lose types invoke an operation on an object. dynamically.

We must now clarify the meaning of “type”. 3. RELATIONS Each type groups together objects that behave similarly. One might define types such as Relations, like databases, types, and Employee, Account, Document, or Image, for operations, are objects-each relation is an example. Every object is said to be an instance instance of the predefined type Relation. In of one or more such types. many object-oriented models, information is carried in the attributes, properties, or As in a programming language with data components of objects. In our model all such abstraction, the type provides a set of information is regarded as associating one object operations that define the way instances of that to another, and is expressed by relations. For type may be manipulated. Since an object may example, one might define a relation between have more than one type, corresponding to the employees and their addresses; or between different roles it may be viewed as playing, it employees and their departments; or between may be manipulated via the operations of several documents, their creators, and their creation types. dates (these types are termed the domains of the relation). As an example, suppose that Jones is a person, an employee and a pilot. If Jones later becomes The association of a particular employee with a a manager, the type “manager” can be added as particular department is represented by a shown. relationship. The relation represents the concept of department membership, by defining Jones Jones the relationships that are valid at any given ------moment. 1 person j ! person 1 I______! ;------3.1 Manipulation of Relations / employee j ’ employee I ------I !------The type Relation provides operations to find, / pilot / I pilot insert, update, or delete specific relationships. ---_------For example, a relation can be queried to find I manager 1 all the employees in a given department, or, ------e-m- since relations in our model are inherently symmetrical, the department of a given Each type provides a separate set of operations employee. that can be invoked on Jones. For example, among the operations defined by the Person type It is sometimes more natural to carry out these might be GetAddress and SetAddress, the manipulations as operations on the instances of Employee type GetManager and SetManager, and the domains. For example, one might want to the Pilot type GetLicenseNumber. Each type ask a particular employee object what its added to an object supplies specific additional department is. This is easily accomplished by capabilities, by providing additional operations. providing operations on Employees such as “GetDepartment”, “SetDepartment”, etc., which Types are full-fledged objects. Certain types simply access the proper relation (compare with are predefined by the model; other types can be the functional data model [Shipman 811). defined by users. The latter is accomplished by creating a Type object and binding operations to 3.2 Generality of Relations it; the operations are written (in one of several programming languages) as functions which take Objects such as paragraphs, images, and parameters and return a single result. documents can be arbitrarily complex structures Operations are treated as objects also. (the operations defined by their respective types define the legal interfaces for manipulating To summarize our concept of an object: them). Since there is no restriction on which types constitute the domains of a relation, such objects may be related by the same mechanism

303 described for simpler objects such as employees, approach in the design of these features- departments, and addresses. Thus, one could although, of course, they will be expressed in create relations to express the correspondence terms of operations provided by predefined between paragraphs and images, between artists types. and the images they have created, or between employees and the voice messages sent to them. REFERENCES

4. OTHER IMPORTANT FEATURES [Abrial 741 Abrial, J.R. Data Semantics. In Our model supports multiple implementations of [Klimbie 741, l-59. the same type. For example, one might define a HashTable type with several alternative [Cattell 831 Cattell, R.G.G. Design and implementations; users of a particular Implementation of a Relationship-Entity-Datum object need not know which kind of hash table it Data Model. Xerox Palo Alto Research is, only that it responds to the same interface. Center, Laboratory CSL-83-4 (1983). Relations may be derived-instead of storing the actual relationships, they are computed as [Chan et al. 821 Chan, A.; Danberg, S.; needed. Because relations are objects with a Fox, S.; Lin, W.; Nori, A.; and Ries, D. specific fixed interface, users of the relation do Storage and Access Structures to Support a not need to distinguish between derived and , Proc. 8th Int. Conf. stored relations-at least when making on Very Large Data Bases (1982 September), retrievals. The view update problem may be 122-130. addressed within the framework of the model by taking advantage of multiple implementations to [Chen 761 Chen, P.P.-s. The Entity- provide special update procedures. Relationship Model-Toward a Unified View of Data. ACM Trans. on Database Syst. 1: 1 As in other similar models, types may be (1976 March), 9-36. arranged into a hierarchy (actually a lattice, since a type may have more than one parent). [Childs 681 Childs, 0. L. Description of a If Employee is a subtype of Person, for Set-Theoretic . Proc. FJCC . example, creation of an employee object will 1968, 557. North Holland. automatically include the Person type. The type lattice facilitates compile-time operation name [Codd 791 Codd, E.F. Extending the resolution; for example, a reference to Database Relational Model to Capture More “GetName” on an employee can be bound at Meaning. ACM Trans. on Database Syst. compile time to the “GetName” operation defined 4:4 (1979 December), 397-434. by type Person. [Dahl & Bubenko 821 Dahl, R.; and Bubenko, J. IDBD: An Interactive Design Tool For 5. CONCLUSION Codasyl-DBTG-Type Data Bases. Proc. 8th Int. Conf. on Very Large Data Bases (1982 The Integrated Data Model offers generality, September), 108-121. power, and flexibility. At the same time, we believe that it provides a basis for building [ Klimbie 741 Klimbie, J.W. and Koffeman, K.L. friendly and natural interfaces. (eds.). Data Base Management. North Holland (1974). Subsets of the model and of an English-like interface have been prototyped. Implementation [Olle et al. 821 Olle, T.W.; Sol, H.G.; and of the model consisted of writing the low-level Verrijn-Stuart, A.A. Information Systems layer to support abstract objects, and then Design Methodologies: A Comparative Review. simply creating each of the predefined types and North Holland (1982), 648~~. writing the operations defined by these types. [Shipman 811 Shipman, D.W. The Functional We believe that a full implementation can perform Data Model and the Data Language DAPLEX. competitively; similar designs ([Chan et al. 821 ACM Trans. on Database Syst. 6:l (1981 [ Cattell 831) have shown promise that March), 140-173. optimization techniques (such as clustering of relationship tuples, and replication of immutable [""G~u~~uo 821 Wong, H.; and Kuo, I. objects like integers) can be successfully Graphical User Interface for applied. Databale Exploration. Proc. 8th Int. Conf. on Very Large Data Bases (1982 September), Work is in progress on the important areas of 22-32. transaction management, synchronization, and distribution. We are taking a fairly conventional

304