Browse Prior Art Database

Technique for Merging Component Databases

IP.com Disclosure Number: IPCOM000114731D
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Document File: 4 page(s) / 208K

Publishing Venue

IBM

Related People

Bent, SG: AUTHOR [+4]

Abstract

An algorithm is disclosed that allows multiple, overlapping, database components from different sources to be merged into a single database and for conflicts to be resolved automatically as well as independently of the order in which the components are merged. This capability allows databases of design components, such as those produced by Computer Aided Design (CAD) and Computer Aided Software Engineering (CASE) tools, to be shared and reused among multiple users and for providing version control capabilities for such components. The concepts apply equally well to various types of database systems including relational, network, object-oriented, active, and deductive.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 31% of the total text.

Technique for Merging Component Databases

      An algorithm is disclosed that allows multiple, overlapping,
database components from different sources to be merged into a single
database and for conflicts to be resolved automatically as well as
independently of the order in which the components are merged.  This
capability allows databases of design components, such as those
produced by Computer Aided Design (CAD) and Computer Aided Software
Engineering (CASE) tools, to be shared and reused among multiple
users and for providing version control capabilities for such
components.  The concepts apply equally well to various types of
database systems including relational, network, object-oriented,
active, and deductive.

      In the following, a component database (CDB) refers to a
collection of components where each component is represented by a set
of attributes.  Conflicts or inconsistencies can arise when two or
more overlapping collections of components are merged.  For example,
different databases may use different unique identifiers for the same
concept or value; or the same identifier may be associated with
different concepts or values.  Fig. 1 shows an example of several
different components (represented as collections of tuples in three
different relations).  Fig. 2 shows the result of merging all of
these components into a single database.

      There are two different kinds of attributes associated with any
component, i.e., core and characteristic attributes.  A core
attribute consists of a unique component identifier, a name, and a
component type.  Generally, only the component name is need be
visible to the end-user; the identifier and type may be hidden.  The
component type is necessary only when more than one generic component
type is required, e.g., for CASE tools, generic component types might
include a requirement, a data process, a control process, a class, or
an entity.  Since there is only one type of component (i.e., a part)
used in Fig. 1, the core attributes consist of only the PartNo and
Name fields in the PartName relation.  A characteristic attribute
links a component to simple, descriptive units of information that
are primitive, i.e., not treated as components.  Examples include
color, weight, composition, size, and cardinality.  In Fig. 1, tuples
in the relation PartMaterial are characteristic attributes.  The
component fringe of a component is the set of all components that are
related to it via characteristic attributes.  In Fig. 1, tuples in
the relation PartSubpart participate in the component fringe since
the "subpart" attribute is, itself, a component.  For example, the
component fringe for component PN0001 includes component PN0002,
PN0003, and all components denoted by the ellipsis.  The component
fringe simply establishes the set of all references to other
components.  These references must be made consistent with any change
of the core attributes of the referenced componen...