Documentum
follows Object Oriented Design (OOD) paradigm.
Every element present in the system whether it is content object that
contains metadata and reference for a specific document or image, or the simply
the metadata exists as an object. To understand the system as a whole we need
to understand the process and assumptions that are inherent in OOD, as well as
the relations among the Documentum objects.
Successful
design of Documentum implementation depends on how well we organize our objects
to meet our specific requirements. Since
Documentum allows simple to complex relationships among documents, we should be
very careful in designing objects to achieve optimum design.
To store any kind of data, Documentum uses the concept of
Object Types. Objects Types are nothing
but a template defining the structure.
Data is stored as object type instance which contains the structure
defined in the Object Type definition.
There are several object types available in Documentum for internal
use. These object types can be extended
to meet our business requirements.
In a nutshell, whatever information we store either it is
a document or media file will be stored in the Documentum as object instance.
All of the Documentum object Types when we create the
repository will start with dm_ prefix. Documentum allows us to extend these objects
to accommodate our business logic. As in OOD, the derived object types share
properties with their parent object types, and on the level of the derived
object type properties can be added.
Documentum passes even the security configuration of the supertype to
subtype. However we can override the
security configuration at the subtype.
In Documentum terminology we call the parent object type
as supertype and child object type as subtype.
Object type hierarchies enable consistency across the enterprise, and it
also provides flexibility that is needed to address the specific requirement in
business logic for individual departments or applications.
Let us discuss some object types in this chapter and we
will discuss other object types as we move to other sections.
Documentum classifies the whole object types into 2
categories.
Persistent Object Type
Objects
which are stored in the repository are termed as persistent objects such as
documents, users, groups etc. All persistent object types are derived from the
root persistent type. Persistent Type has the following properties
r_object_id: This property is assigned by the content server
for all persistent types and is unique in the repository.
i_vstamp: Whenever an object is modified, content
server updates this attribute and this is used internally by Documentum.
i_is_replica: This attribute is used in the federated
environments. If the repository is
configured to a federation and if the object is participating in the
replication then the property will be set as TRUE.
Non Persistent Object Type
Non
persistent object types are used to store information which does not exist in
the repository. They will be created at
runtime such as docbaselocator, collection objects etc.
Content Objects
All the content objects are stored under dm_document
object type. Out of the box this object
type does not have any properties of its own.
However this object type inherits all of the properties from
dm_sysobject which is supertype for this object type. There are many properties defined in the
dm_sysobject object type like name, subject, title, keywords, content location
etc. We will discuss about the
properties in the next section.
Content less Objects
Even though ECM primarily addresses unstructured content,
there are certain cases where we need to store structured information which has
only metadata without content. For e.g.,
we may need to store all the departments information in an organization which
may not have any content associated with that information. Documentum uses contentless objects for many
purposes internally such as user’s information, ACL’s information, policies
information etc which do not have any content object associated with them. We
can assign same set of security, auditing settings to contentless objects as we
can do with content objects.
Folders
Since ECM
mainly deals with unstructured information, it provides structured format for
storing all the documents. Folders in Documentum are similar to the folders in
normal file system. It provides
modelling for the documents storage.
Folders are commonly used to structure content elements in some manner
for example storing all the documents related to a case at one place.
Folders are very important in Documentum as these provides
additional security feature in Documentum.
We will discuss more about folder security in security services section.
Similar to documents, folders can also be extended based
on the business logic. All the
properties of the supertype will be inherited to the subtype and we can add
additional properties in the subtype.
Object types can be categorized into 4 types.
Standard:
Most of the objects in Documentum are considered as standard object
types. All of this object type’s storage
in internal RDBMS system is similar.
Aspects: Sometimes we may need to add dynamic
properties to the object types based on the business logic. We can achieve these using Aspects. However custom programming is required to add
dynamic properties to an object type.
Light
weight types: These are introduced
in 6.5 version of content server. These
object types are used for high rate content ingestion and reducing the storage
capacity. To use this feature we require additional licensing.
Shareable
objects: These types are the supertypes for light weight types. The shareable object that is sharing its
properties with the light weight objects are called parent objects and the
lightweight object is called child object.