Unique Identifiers for Types

When you define a type, you must define how business objects of that type will be uniquely identified.

This page discusses:

ID Keyword

The ID statement defines the unique identifier for that type. By default 3DSpace uses object identification numbers (OIDs) for everything in the database, so each object that will be represented in 3DSpace from the foreign database must also have an OID. 3DSpace will generate an OID and store it persistently in the database, as long as the persistentforeignids system setting is true (the default).

The ID is ideally an integer column, and the integer must be between 0 and 16777215. However, if you do not have an integer column for an object type or the integers go beyond the acceptable range, you can use the mapped keyword after the ID column specification for a type. For example:

type EMPLOYEE {
id EMP(EMPNAME) mapped;
...
}

Objects of one type can be scattered among multiple tables. Even so, all mapped objects of one type must have a common ID column, either real or created through a join.

If you used ROWID in a table description, these columns must be mapped when referenced in a TYPE description. For example:

type Department {
     id DEPT(ROWID) mapped;
     ...
}

Creating an ID From Multiple Table Columns

If one table column does not provide enough information to make the object unique, you can specify a combination of two or more columns as the ID of a type or relationship. In this case, no column is identified as primary, and the type’s ID statement indicates the columns that should be used. However, the size of and order in which the columns are listed is important: all columns must be the same size or the smallest column must be listed first in the ID statement.

For example, if a table is defined as:

TABLE Vendors {
     SUPPLIER string;
     COMPONENT string;
     ...
}

You could specify the type using both of these columns as the ID:

type {
     id Vendors(SUPPLER,COMPONENT) mapped;
     ...
}

In this case, the size of the COMPONENT column would have to be greater than or equal to the size of the SUPPLIER column.

This example is not part of the human resources database or the mapping file in the sample Adaplet.