Modelling CAD-Objects by abstraction

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 74 – 10/1987

Thomas Berkel, Peter Klahold,

Gunter Schlageter, Wolfgang Wilkes

Modelling CAD-Objects by abstraction

Abstract

MODELLING CAD-OBJECTS BY ABSTRACTION

T. Berkel, P. Klahold, G. Schlageter, W. Wilkes

U niversity of Hagen Praktische Informatik I

Postfach 940 D-5800 Hagen West-Germany

In the field of technical applications ( CAD/CAM) the representation and administration of complex objects and versions is of great importance. This paper presents a universal model for these aspects, and outlines a corresponding language. The model is based on an abstraction mechanism which relates objects on different levels of abstraction. Each object represents a certain view of a real-world object, tailored to the demands of the user (person or program) of the database. Tue mechanism of abstraction allows to create new objects by specializing or generalizing existing objects. Furthermore, the abstraction relationship can be used to model the concept of versions: The common properties of versions are expressed by a more abstract object. By weakening the separation of types and objects this model allows to represent individually structured objects (in particular CAD-objects) as well as homogeneously structured data ( as handeled by today's database systems) in an integrated way.

1. lntroduction

By semantic and object-oriented data models /BrMS84/ mechanisms of abstraction ( especially generalization and classification) have been introduced which are used to structure the different types of objects in the course of database design. These abstraction mechanisms allow to extract the common properties of various object-types and to deal with type hierarchies. Thus, programs can be written which are not only geared to a specific object-type but also valid for several object-classes.

Tue idea of abstraction turns out to be an important concept for object modelling in the field of CAD/CAM, too. Tue evidence of this idea can be seen in the theory of methodical design for mechanical engineering /SeWe86/. Unlike conventional database applications, design applications require highly flexible data structures which have to be considered by the mechanisms of abstraction. Especially we have to manage the component structure of the objects which results in the requirement of relating components on different levels of abstraction.

Another important issue in the CAD/CAM area is to find a unifying model for tbe version \ concept. lt will be shown that an appropriate mechanism of abstraction is a powerful tool ¹ for this problem, too.

In this paper, an object-structure-model is introduced, which connects objects by an abstraction relationship and

arratges

them in an abstraction hierarchy. Tue objects play of this hierachy two roles: At first, they have properties of types, they define the structure of other objects. Secondly, they are used as objects with there actual values. lt will be shown how this abstraction relationship can support existing mechanisms for representing CAD/CAM-objects, especially the component relationship and the modelling of versions.

Westart by sketching some observations concerning the use of composite objects in CAD environments and possible views of the concept of versions, which leaded us to the definition of this object-structure-model ( chapter 2). Then we explain the model more closely ( chapter 3) and present a framework of a data manipulation language for dealing with objects of the model ( chapter 4 ).

2. Objects and Versions Design-Objects

Design objects have a complex internal structure, which could be modelled, for example, by linking flat, relational tuples /LoP183/, by NF2-tupels (/JaSc82/, /Dada86/), or by molecular objects /BaBu84/. They are assembled to larger design objects, so that the objects are integrated into a hierarchy of component relationships /KeBe87/. In this paper

- 2 -

we presume that the component relationsship is expressed by references /KWUK87/ (see figure 1).

©

I "

0 0

Fig. 1: Composite object with structured attributes

At the very beginning of the design-process often neither the exact type of the components nor the concrete component objects are known. The design process just consists in creating new descriptions of objects by updating and refining.

In order to document this process, the object model has to provide mechanisms to represent the object before its final completion as well as the restrictions for the further design process. These restrictions may be seen as an object description at a higher level of abstraction. Subsequently, the ultimate detailed object representation is being developed by means of gradual refinement.

In conventional object models it is hardly possible to represent this process of refinement.

An object has to be fully defined, and all attributes have to get a value the type of which is fixed in the schema. References are typed as well: They have to reference objects of specified types. If we allow a reference to be unresolved, i.e. it has not to be bound to a specific object, we can achieve more flexibility: In this case the reference only describes

' ' _' '

'

'

'

C;gj _;)

Fig. 2: · Refining of a type-reference to a specific object

how objects have to look which may be linked in later on, it can be interpreted as a reference to the component-type. Thus, at the beginning of the design process the reference points to a set of components (full line at figure 2). During the design-process a specific component is selected and the reference is set to it (broken line ).

From this point of view the gap between types and objects becomes narrower: Objects may reference other objects or. types; in the latter case the type determines the structure of objects, which will replace it in later steps of refinement. But the strict separation of type and object allows only this particular level of refinement. lt would be desirable to be able to represent more levels of refinement which would lead to a further weakening of the strict separation between types and objects.

This is also illustrated by the following interpretation of type-references: Because an object-type also indicates the set of objects of this type, the reference may be interpreted as pointing to the set of these objects. Hence, the only possible step of refinement consists of the selection of one of the elements of this set (see figure 2). This notion of set is not precise enough and very often the possible set of components needs to be restricted. For instance, in the course of assembly of the object 'cpu' it might be desirable to reference only the 'alu's' with a register width of eight bits instead of all alu objects. Generally, it should be possible to define set-references for any partial set of the type-set (see step 2 of figure 3).

A c:::i

Step 1

1

A c:::i

•

_Step2

Fig. 3: Refining of references

A c:::i

•···+ ~~ ^t=J

Step n

Altogether, the process of design may be represented as follows: A general definition of components is gradually refined, i.e. the set of possible components is reduced step by step until finally a definite description of the components remains (see figure 3). Thus, by means of a stepwise specialization the abstract description of the object is refined to a concrete object. In our model these steps of refinement are represented directly by a flexible abstraction relationship between objects.

- 4 -

Versions

Tue concept of version may be seen as a mechanism of abstraction, too: Versions of an object have common properties /KSWi 86/. These common properties may be reduced to the name of the object, but in other cases, they describe, for instance, the common interface of the versions of a VLSI-chip /BaKi 86/, and very often the versions of a versioned object have the same structural properties, i.e. the same type (/DiLo85/, /KaCB86/). Altogether, these common properties represent an abstract view of the versions. This view also imposes constraints for the creation of new versions.

Most of the version models only offer this one-level view to the version concept. But there are two ways which lead to a multi-level model of versions: On the one hand, additional higher levels result from the integration of the concept of types, since the type represents an abstraction of the (versioned) objects, namely their structure - as well as the object represents the common properties of its versions. In figure 4 attributes describing common properties of all versions are represented by the object and the structure of the object is defined by the object type.

On the other band it is desirable to be able to add lower levels: What an object is and what a version is, is not definitely clear. Drawing this line is up to the user. Greater

!a1j b1j c1 jl

~

j b2 j c2!

la

¹

1b31c3 ^I

!a

¹

il)i I lla2liJ 1

1 a³

jbz

^{1 1}

\a3j b41 c4j\ a3 j b5 I cSj

1 a

3j b6jc6

¹

Fig. 4: The hierarchy of types - objects - versions

t.

..

j

a2! b7 I c7 jl

^{a2 j}

ba

^j

caj

1

a2j

b9

j

^{c9 I}

objecttype

objects

,=x_ flexibility is achieved by a multi-level version concept, which integrates 'versioned versions'. While a user is able to see an object V as the version of another 'more abstract' object 0, another user, who is looking one level deeper, is able to see the versions of the object V. To him, V is the more abstract object describing the common properties of the matching versions (see figure 5). Tue goal of our model is to offer mechanisms for dealing with versions in these multi-level ways.

objectO

V1 V3 versionVi

1 V31 1 V32 V33 V34 1 V35 V36 versionV3i

Fig. 5: Multi-level versions

In this paper we describe a model where both aspects of the representation of objects are integrated by an abstraction mechanism. Tue basic ideas of the model are

to represent abstract views on objects by other objects

(1) tobe able to integrate abstract objects into a component relationship (2) to be able to describe the common properties of versions by single objects to consider abstract objects as representatives of sets of objects.

3. The Object-Structure-Model

Properties of objects are described by attributes. An attribute is a pair (attribute-name, attribute-content). Conventional object-models describe the domains of the attributes of an object by the object-type. Every object belongs to exactly one type, and all objects of a type possess the same attributes ( classification).

As we saw in the previous chapter, there are many reasons to weaken this strict separation of type and object and to make the type-object-relationship more flexible. The starting point for achieving this goal is a somewhat different view on this relationship: We represent an object-type by just another object (in the following called meta-object) which can be seen as a template for the objects of this type. With the classical understanding of type the attributes of this meta-object do not contain values but the domains of the

, - 6 -

attribute-contents of the objects. So the meta-object gives an abstract view on the objects the type of which it describes, and it is linked by an abstraction-relationship to these objects. Via this abstraction-relationship the lower level objects inherit all attributes together with their contents from the higher level meta-object. Thus, ist is clear which attributes the subordinate objects of a meta-object possess and to which domains the contents of the attributes belang. Assigning a value to an attribute of an object is seen as a specialization of the inherited attribute, its domain is restricted to exactly one value. By linking meta-objects by the abstraction-relationship the generalization-relationship between types can be represented.

The abstraction-relationship is the key for making the type-object-relationship more flexible: Not only the existence of attributes is transferred from one object to another, but also contents of these attributes may be inherited by objects. Thus, abstract objects can not only describe the common domains of attributes, but also the common properties of specialized objects (which means the contents of attributes). By this the model is a bridge between the type-oriented models of the database world and the prototype-models of the AI-world, which especially support the single-object-oriented use of objects.

Thus, our model looks as follows: lt is based on the prototype approach which means that an object is self-contained, its attributes are not described by a separate 'object type'. But part of the object may be described by other objects, which are related to it by the abstraction relationship. This relationship connects a higher level abstract object with a lower level specialized object. The abstraction relationship restricts the properties of a specialized object: lt inherits the attributes of the abstract object, and inherited attributes may only be altered within the limits set by the attribute contents of the abstract object: lf the content of the inherited attribute is already a simple value, it may not be changed, whereas a domain may be restrifJ~~L\P a smaller domain, in the extreme case to a simple value. So the abstract object impo'ses integrity constraints on the appearance of its specialized objects, and it even can specify that an attribute has a specific value for all specialized objects.

Since the abstraction relationsship is not restricted to one level, it builds a hierarchy in which the objects are embedded. Thus, an object may play the role of an abstract object and the role of a specialized object simultaneously. In the role of an abstract object it determines attributes and their contents for its specialized objects, so that it looks like a

"type-object". On the other band, in the role of the specialized object it inherits the attributes and their contents from its abstract object(s), so it looks like a "normal" object.

By this hierarchy we can see sets of objects not only in the conventional type-oriented way, but we get more flexibility, since attribute values can be predefined by abstract objects. For instance, we may install several levels in the hierarchy between the pure

"meta-object" ( consisting of "domain-attributes" only) and the "real objects" ( consisting of

"value-attributes" only).

With respect to the hierarchy of the abstraction relationship an object may be created in three ways:

- without relating it to existing objects, - as a specialization of some objects, - as an generalization of some objects.

If an object is created as a specialized object of some other objects, it inherits all attributes and their contents from these objects.

If an object O is created as an abstraction of a set of other objects Si, it must be a generalization of these objects:

(1) All attributes of O must ex.ist in each Si;

(2) For each attribute Ao of object O with the content C(Ao) the following holds: In all objects Si the content of the attribute Asi (

=

C(Asi)) is a specialization of C(Ao).

An object may be modified in three ways:

(1) by restricting the inherited value range of an attribute, with the special case of setting it to a fixed value;

(2) by defining new attributes (attribute names, attribute contents);

(3) by modifying attributes which are not inherited.

Using these mechanisms a complete abstraction-hierarchy can be constructed, not only top-down (specialization) but also bottom-up (abstraction). An example is given in the appendix. All creation-techniques can be combined to embed new objects into the hierarchy (not only as leaves or root-elements). From this point of view a new object is an abstraction of lower-level objects and a specialization of higher-level abstract objects. Tue structure of the hierarchy is not restricted to a tree. lt is also possible, that several objects define the integrity constraints for a common specialized object.

Advantages of the proposed model

Our object-model removes the strict separation of types and objects: An object has an effect to its specialized objects like a type, whereas its own structure is partly defined by more abstract objects. This results in possibilities for modelling objects in a very flexible way. In particular a single object can be designed more individually: Tue structure of an object is not fixed for the whole life by its object type, but can be altered and extended.

This precisely reflects the designer's point of view, where the individuality of an object is much more important than in conventional database applications.

- 8 -

Since the abstraction relationship is defined between objects and not between object-types, an abstract object represents other objects by describing their common properties. This mechanism effects the component relationship, too: the relationship between an object O and its components Ci is realized by reference-attributes in 0. These reference attributes are also subject to inheritance: References to components can be inherited and can be refined in specialized objects. A reference to the object Ci is refined by setting the reference to another object V, which is a direct or indirect specialization of Ci (see fig. 6). So the abstract component will be substituted by a specialized component .

..

Fig. 6: Inheritance of references

Thus, it is possible to define the component-structure of an object at first on an abstract level, and afterwards, during the design-process, to refine the components more and more. In the course of design the abstract object sets the conditions for further refinements. Therefore, the proposed abstraction-mechanism is a suitable instrument to describe the top-down-development of a design. The abstract object represents as well the set of related specialized objects (which may be distinguished only by particular attribute-values). This allows, that variants have not to be selected before an object is really assembled. So, even more flexibility is given to the component-structure.

Moreover, the version concept can be modelled directly by the abstraction relationship:

The common characteristics of the versions are represented in an abstract object, while the specific data of the versions are stored in specialized objects. Therefore we shall use the terms "version" and "specialized object" sometimes synonymously. By defining the abstraction relationship upon objects it is possible to express the relationship between an abstract object and its versions in a direct way. Compared to other version-models this concept for version-modelling offers further advantages:

(1) Versions need not to have a unique structure, the set of attributes can be individually extended and refined.

(2) Versions can also be versioned objects, because every object of the abstraction-hierarchy can play the role of an abstract object as weil as the role of a version. So we get a multi-level version-concept.

(3) An object may be a version of several abstract objects. So, different aspects of version-sets can be represented by different abstract objects. For example, a version can separately inherit different interfaces of a VLSl-chip ( connection-pins, time behavior, etc.) from different abstract objects.

To summarize, the use of the abstraction relationship between particular objects based on the prototype-approach solves many requirements of CAD/CAM-environments not satisfactorily provided for so far.

4. The Framework of a Database Language

In this chapter we demonstrate possibilities of working with our model by defining a framework for a database language. Tue power, with respect to design-applications, will be shown by self-explaining examples.

At first we describe elementary operations for the creation and the manipulation of objects and the abstraction relationship between them. Then, a query language for the abstraction hierarchy is introduced. Only the model-specific constructs will be outlined;

the other parts of the language (logical operators, nesting, etc.) are presumed. An SQL-like notation is used to make it more easy to understand. Tue FROM-clause is not used, because objects are addressed by an unique pseudo-attribute name.

Some naming conventions: Objects will be specified by capital letters, attributes by small ones. X.a means the attribute 'a' of the object 'X'. Tue values of attributes are enclosed by quotes. Optional language-constructs are indicated by '[' and ']', identifiers by ' < > . Tue term 'set of objects' specifies the objects which are selected by any retrieval command (see below).

4.1 Creation and Modification of Objects

Tue creation of an object is accomplished by:

create < name >

create [ < name >]

as abstraction of < set of objects >

as specialization of < set of objects >

Tue first case allows the creation of a named object. Tue object gets its structure (attributes and values) by the change-command (see below). In the second case, additionally, the abstraction relationships of the newly created object to already existing objects are defined. If a specialization relationship is described, the new object inherits all attributes and their contents from its fathers. If the generalization relationship is used, the new father-object gets the attributes which exist in all sons. So it is guaranteed, that the insertion of new objects into the abstraction relationship does not lead to inconsistencies.

- 10 -

In the second case the definition of an object name is optional, since access to the object is possible via the abstraction relationship.

The second important command is 'change'. lt allows to change the contents and structure of an object.

change < set of objects >

add remove update

< attribute name > < :content >

N ewly created objects may get any structure and any contents. lf an object inherits attributes, changing of these attributes is only allowed, if no conflict arises with the integrity constraints which are defined in the abstract object. Especially the update- and remove-function must be checked. Adding of attributes is always possible, but, of course, all specialized objects inherit the new attributes and are altered by this operation, too.

There exist additional commands for insertion and deletion of relationships between objects and for removing objects. Since these operations are not essential to understand the key ideas of our model, we shall not detail them further in this paper.

4.2 The Query-Language

For the retrieval of objects the select-command is used. In contrast to the usual select-from-where clause in SQL, the from-part is not necessary. In SQL every variable used in the select- or where-clause is typed, and the type is attached to it in the from-clause. Since in the proposed model separation of type and object does not exist, the structure of an object is only known by accessing it. Thus, on principal the structure of an object can be determined not before .runtime. (possibilities for handling type-oriented

11o:ibf\rJ· ,...~ ,,h„h• '." .. e. ...

queries see below), such that no attaching 6f structural information to variables is possible. Like in SQL the select-part describes how an object will be displayed (projection) while the where-clause describes what objects will be displayed ( qualification).

Tue most simple form of the select-command is

select X

where X.name = ^'a'

This query qualifies the object with the unique intemal or extemal name 'a'. Tue result of the query will be the object in its own structure; for another object 'b' the number and domains of attributes will possibly be different. Tue attribute may contain specific values or any generalized range of values. lt is possible - like in SQL - to define any predicate . and nest such statements.

In addition to this elementary retrieval the query language has to consider the following aspects to make it easy to use the full power of the model:

- Qualification by using the abstraction relationship - Predicates on the existence of structure

- Interpretations of objects - Definition of the result-type ·

4.2.1 Qualification

Exploiting the Abstraction Relationship

In order to take advantage of the abstraction relationship, the following predicates can be used:

< object-var > is [ < level-par >] abstraction of < object-var >

< object-var > is [ < level-par >] specialization of < object-var >

with (X is abstraction of Y) <

=

> (Y is specialization of X).

Tue query

select X

where Y.name = 'a'

and Xis specialization of Y

gives all specializations of the object 'a'. Tue optional level parameter allows to restrict the qualification to specific . _ vels of the abstraction hierarchy relative to an object. lt can be used for accessing specific levels, e.g. 'X is (2) abstraction of Y' - or entire (sub )hierarchies. 'X is (1..max) specialization of Y' qualifies all specializations of Y, i.e.

the whole subpart with Y as its root. With these level-oriented predicates all possible qualifications referring to the abstraction relationship may be formulated. Especially, it is possible to access the roots, the leaves (the most specific objects), and the hierarchy as a whole ( the set of all objects ).

Predicates concerning the existence of structure

Selections on different levels of the abstraction hierarchy lead to heterogeneously structured objects. For this reason, it should be possible to base queries on the structural properties of the objects. This can be accomplished by the following predicate:

< object-name >. < attribute-name > exists

- 12 -

With this predicate the query

select X

where X. y exists

qualifies those objects, which have the attribute 'y'. A predicate that includes attribute-values also contains the existence condition for this attribute. Thus

"X.y

=

'a'" and "X.y exists and X.y

=

^'a"'

are identical.

4.2.2 Defining the Result of Queries Interpretations of an Object

So far the selected objects have been seen with their full structure and their contents. Tue flexibility of the object representation leads to a set of heterogeneously structured objects in which an attribute may represent either a range of values or a specific value. This wide range of possible contents for an attribute is a problem for applications written in type-oriented languages. Also the interactive user can see an object of the abstraction-hierarchy under different points of view. Therefore the following interpretations of an object should be supported:

object as a node in the abstraction hierarchy

Here the selected object appears with its own, specific values. This is the normal view to an object; it is created by simple object-variables in the select-clause (select X).

object as a representative

During the design-process it is often desirable to apply tools to abstract objects which contain restrictions for further design steps only. Usually, these tools work on fixed values and not on ranges of values. Thus, they need a specialized view of the abstract object, a representative, where all the attributes are single values. In order to achieve this a function by_example can be used in the Select-clause:

select X by _ example where X.name = ^'a'

gives the object 'a' with all (range) attributes having any (random) value within the given range. This by _ example mechanism can be refined by the definition of defaults or a formula ( e.g. average value ). Of course, by _ example can also be applied to selected attributes of an object.

- object as a 'type'

All specialized objects inherit the attributes from the respective abstract object.

Therefore, these specializations may also be understood as instances of a type described by the abstract object. During a normal selection these instances appear in their own, heterogeneous structure. In order to see them with a homogeneous structure the function project_ on may be used.

select Y project_on X where X.name = 'a'

and Y is _ specialization _ of X

~~bplies all specialized objects of 'a' in the structure defined by 'a'. Thus, by means of the project_on function it is possible to provide the conventional view with relation (as type) and tuple (as instance) on the objects of the abstraction hierarchy.

Especially for not object-oriented, type based languages, these different views on objects simplify the handling of the abstraction hierarchy. Project_ on makes a type-oriented access to objects possible and by _ example guarantees that any abstract object can be processed.

In addition, an interpretative style of working has to be supported. lt allows the processing of objects the structure of which can be determined only during the access. Here the structure has to be analyzed by the application before the attributes can be accessed.

Definition of the Result-Type

Tue results of the examples discussed so far have been heterogeneously structured object sets (unless the described project-function is used). To define a certain result structure a simple listing of the interesting attributes is required. With

select X.a, X.b

where Y.name = 'i' (*) and Y is abstraction of X

all the specializations of the object 'i' are projected on the attributes a and b.

In the abstraction model it may also happen that some of the qualified objects do not contain the attributes specified in the select-clause. This can be handled by a specific null-value 'not_defined' which indicates that the respective object does not possess this attribute.

- 14 -

By this definition the result set of the following question is only a subset of the result set qualified by (*):

select X.a, X.b where Y.name = 'l' and Y is abstraction of X and X.a exists

and X.b exists

This example illustrates that the select-clause only describes the appearance of the result.

lt does not influence the qualification of the result objects. If we only ask for objects which have a particular attribute, this has to be defined explicitly as a qualification predicate - irrespective of the projection in the select-clause.

5. Conclusion

In this paper we have introduced an object-model that renounces the conventional restrictive typification of objects and that defines an abstraction relationship on the object level. By this idea we achieve a greater flexibility in object modelling: We are able to reference components on different levels of abstraction which leads us to a better representation of the design process. By storing the common properties of versions in a more abstract object the semantics of the relationship between an object and its versions can be expressed more precisely. Problems and possibilities of the use of the rnodel have been demonstrated by defining the framework for a language for object definition, rnanipulation and retrieval. This framework shows that the full power of the rnodel can be provided at the language level.

Tue starting point of our considerations was the modelling of objects in technical databases, but the limit of its applicability is by far not reached. Because of the ernphasis on the idea of abstraction, this rnodel is especially suitable for the data-adrninistration of object-oriented systems. For instance, it seems to be possible to realize a data adrninistration system for the SMALLTALK programrning systern on the basis of the suggested model. Our object-model is also a good basis for the connection of databases and knowledge-representation-systems ( e.g. LOOPS), especially because some of the latter also use the prototype approach ( e.g. for the rnodelling of default-values /LaSrn84/, /FiKe85/).

r::ry,y·' , t

Though the strict separation of type and object does not exist any rnore, our rnodel can also work 'type-oriented': Tue transition from one abstraction-level to another rnay be seen as a transition from type to object, if structures specifically defined in the specialized object are not considered. Queries relating to inherited attributes of a version-set may be translated and processed just like queries in typed databases (e.g. in the relational SQL).

Tue more the individualization of the objects is used for data-modelling the more queries must be processed individually. This is not a disadvantage in the mentioned fields of application where the style of work often is single-object-oriented. In particular, in those areas it is not as important to have a query component that works on many similiar objects as to have one that works individually on a few, very complex objects.

Our model supports both strategies of working in a uniform way. Single-object-oriented working (e.g. with object-oriented languages) as well as the conventional, type-oriented working (like in present database systems) are possible on the same database.

6. Literature

/8a8u84/

/BaKi85/

/8rMS84/

/Dada86/

/Dilo85/

/FiKe85/

/GoRo83/

/JaSc82/

/KaCB86/

/KeBe87/

/~UK87/

Batory, D.S. and Buchmann, A.P.: Molecular Objects, Abstract Data Types, and Data Models: A Framework. Proc. VLDB, Singapore 1984

Batory, D.S. and Kirn, W.: Modelling Concepts for VLSI CAD-Objects. ACM TODS 10, Sept. 1985

Brodie, M.L, Mylopoulos, J. and Schmidt, J.W. (Editors): On Conceptual Modelling.

Perspectives from Artificial lntel/igence, Databases, and Programming Languages.

Springer New York, Berlin, Heidelberg, Tokyo 1984

Dadam, P., et.al.: A DBMS Prototi;pe to Support Extended NF2-Relations: An lntegrated View on Fiat Tab/es and Hierarchies. Proc. ACM SIGMOD, Washington 1986

Dittrich, K.R. and Lorie, R.A.: Version Support tor Engineering Data Base Systems. IBM Research Report RJ4769 (50628), San Jose 1985

Fikes, R. and Kehler, T.: The Role ot Frame-Based Representation in Reasoning.

Comm. ACM, Vol. 28, No. 9, Sept. 1985

Goldberg, A. and Robson, D.: Smalltalk 80, the Language and its Implementation.

Addison-Wesley, Reading, Mass. 1983

Jaeschke, G. and Schek, H.-J.: Remarks on the Algebra ot Non First Normal Form Relations. Proc. ACM SIGACT-SIGMOD Symp. on Principles of Data Base Systems, Los Angeles 1982

Katz, R.H., Chang, E. and Bhateja, R.: Version Mode/Ing Concepts for Computer-Aided Design Databases. Proc. ACM SIGMOD, Washington 1986

Ketabchi, M.A. and Berzins, V.: Mathematical Model of Composite Objects and its Application for Organizing Efficient Engineering Databases. IEEE Transactlons on

Software Engineering, 1987

Klahold, P., Köhler, D., Ungerer, M., and Wilkes, W.: Representing Design-Objects in Relational Database Systems. EIS-Workshop, 1987 (in German)

- 16 -

/KSWl86/

/laSm84/

/LoPl83/

/MyBW80/

/SeWe86/

Klahold, P., Schlageter, G. and Wilkes, W.: A General Model for Version Management in Databases. Proc. VLDB, Kyoto 1986

lafue, G. and Smith, R.G.: Implementation of a Semantic lntegrity Manager with a Knowledge Representation System. Proc. Expert Database Systems, 1984

Lorie, R. and Plouffe, W.: Complex objects and their Use in Design transactions. Proc.

Engineering design applications, ACM SIGMOD, San Jose 1983

Mylopoulos, J., Bernstein, P.A. and Wang, H.K.T.: A Language Facility for Designing Database-lntensive Applications. ACM TODS 5, June 1980

Seiffert, H. and Weber, C.: Maschinenelemente in Lehre und Forschung - Fortschritte durch Methodisches Konstruieren. Workshop Methodisches Konstruieren von Maschinenelementen (MeKoME), Mailand 1984, in: Schriftenreihe Workshop - Design - Konstruktion, Hrsg. V. Hubka, Heuristica Verlag Zürich 1986 (in German)

Appendix

The following example demonstartes the usage of the query language in an abstraction hierarchy

---

'example' - l~t lb 1-100 /c1 - 100 / ~tring ~,;.,

~

1~ 1~

⁰

1~

1; ib lc

1 38 : 1-50

'my_object'

-1:

^l~s l~up1 / ebool / f real ¹

~

/

1: l~s

I~/

^{1 dtup1.1I8 true}

^I

^{f 3.0}

l~s lc96 · / dtup1

.2/

^{~alse / ~-}

7

1: l~s ,~

¹ ~up1 .31 ~rue 1 ~-1

1~

^{/is I~ · 1 ~up1}

^.4/

^1alse

^{I J.6}

note: - 'example' can be seen as a type defining the attributes a,b,c,d - specializations of 'my_object 'can be seen as versions of 'my_object'

with common values for the attributes a,b,c

Select unique X.a, X.c, X.g where Y.name = ^'example'

and X is specialization of Y and X.a = ⁷

a C

7 4 7 1 - 50

g not def true

1 ~up3 1 t~ue 1

~ "'-

select X

where Y.name = 'example' and Z is max abstraction of Y and X is 1.. 3 specialization of Z

select X.a , X.b, .X.c, X.d, X.e, X.f, X.g where Y.name = 'example'

and Z is max abstraction of Y and X is 1 .. 3 specialization of Z

select X project_on Z where Y.name = ^'example'

and Z is max abstraction of Y and X is 1 .. 3 specialization of Z

select X by_example where X.name= 'example'

select X

where Y.name = 'example' and Y max is_abstraction_of X

a b C d

int 1-100 1-100 string

7 38 4 tup3

6 44 1 tup2

4 35 96 tup1

int 1-50

7 38 1 - 50 tup7

4 35 96 tue 1

a b C d

int 1-100 1-100 !~ring r

7 38 4 tun~

6 44 1 tuo~

4 35 96 tue

iirtt 1l,,SII not d n d 7 38 1 - 50 tuo7

4 35 96 tue

a b int 1-100 7 38 6 44 4 35 int 1-50 7 38 4 35

1 0 l 100 100 ^J ·n·I

a b C d e

4 35 96 tuo1.1 true 4 35 96 tue1.2 false 4 35 96 tup1.3 true 4 35 96 tup1.4 false

g e f

bool true

bool I real 1

8 f g

ot def not def not def not de ¹ not def not def not de • not de1 not def not de f not de• not def not de not def bool not def not def true bool real not def

f 3.1 9.7 8.1 4.6