Documentum Resources

Properties also called as Attributes define the structure of the object types.  For every object type, there are set of attributes defined to it to identify the nature of the object.  When an object instance is created from an object type definition, we can describe the instance using the attributes. All persistent objects will have minimum of 3 attributes as described earlier. 

 

There are 2 kinds of attributes.  They are single valued and repeating valued.

Single valued attributes are those whose value can be only one item i.e., a document can have only one name for it such as vendor proposal. These kinds of attributes are called single valued attributes.

 

Sometimes we may have multiple values for a property such as a document can be authored by multiple persons.  To store such kind of properties Documentum provides repeating attributes so that we can store multiple values under one property name.

Documentum has different mechanism to store each kind of attributes.  To understand how the attributes are stored in the underlying database, we need to understand how the object instances are stored.  Let us look at how object instances are stored in the database.  Each object type represents two tables in the database one prefixed with _s and other with _r.

 

 

 

 

FIG: Table structure for object types

 

To store the Attributes information Documentum provides different data types such as int for numeric values, string for text characters etc.,

 

By default all the attribute for an object type are Qualifiable.  Non Qualifiable attributes do not have any column in the underlying database instead it stores these values in i_property_bag property of dm_sysobject.  Since dm_document is the subtype of dm_sysobject, i_property_bag attribute is inherited to this type as well.  Non Qualifiable attributes are stored in serialized format in the database table. If the size of the attribute value exceeds the size of the 2000 characters, the value will be stored in r_property_bag attribute. This attribute will be added to the object type when we specify the attribute as Non Qualifiable.

 

The purpose of Non Qualifiable properties is to improve the fetch performance by the content server.  Performance will be improved because the attributes are stored in dm_sysobject_s and/or dm_sysobject_r tables which eliminate the need of applying joins in the underlying database.

Limitation of Non Qualifiable attributes are that they cannot be referenced in conditional statement of a query unless the query is FTDQL query. However they can be used in the select statement of a query.

Documentum identifies the attribute as Qualifiable or Non Qualifiable by attr_restriction attribute in the dm_type table.

 

NOTE: The length of Non Qualifiable property with string datatype must not exceed the value of max_nqa_string key in server.ini file.

 

Property Bag is a special property to store the Non Qualifiable attributes and Aspect properties if they were configured with fetch optimization.

Property Bag is implemented by using i_property_bag attribute. 

We can store single valued attributes as well as repeating valued attributes in the property bag.