Documentum Data Models.ppt

9 November 2022
Privileged & Confidential
Documentum - Data Model
Documentum 6.5 E3 Training Material

9 November 2022
• Introduction to the data modeling options with
Documentum
• Understand the data representation at the database
level
• Chose the best way to model data in Documentum
based on customer requirement
Module Objectives
Documentum 6.5 E3 Training Material 1

9 November 2022
• E2 Level training for Documentum
• E2 level training for DFC/DFS
• Experience with Documentum Composer
• Documentum Composer 6.5 is installed and
configured to a repository
Prerequisite

9 November 2022
• Documentum provides several ways to model
application and document metadata –
– Object Type Hierarchy
– Registered Tables
– Aspects
– Lightweight & Shareable Objects
– Data Tables
– XML
Data Modeling Options

9 November 2022
Before deciding which data model to architect , the
following points need to be considered
– Whether and how much static or dynamic is the data
model ?
– No of data types needed
– No of objects that would be created for each data type
– Security requirements
– Retention Model
– Do many objects share the same attribute values?
– Type of queries that would be issues against the model
Choosing a data model ?

9 November 2022
• It represents the customer problem accurately
• It is intuitive
• It is easy to form queries against the model
• Can easy scale to support large number of objects
Features of a good data model

9 November 2022
• Documentum Object Types exist in hierarchy , with subtypes inheriting
and extending the properties of a super types .
• An object can belong to the super types, or the sub type or both .
• An object type is like a java class. The definition of an object class consists
of a set of properties and methods. When you create an object , you
choose the type for the object. The newly created object will have the
properties associated with the type and also the methods will be invoked.
• Example – dm_folder is a sub type of dm_sysobject and
dm_cabinet is a sub type of dm_folder. Hence dm_folder
inherits all properties of dm_sysobject and dm_cabinet
inherits all properties of dm_folder and in turn of
dm_sysobject.
Option 1 – Object Type Hierarchy

9 November 2022
• Content Server stores properties of each object type in two tables:
• <type>_s table stores the single values properties of the object
• <type>_r table stores the repeating value properties of the object
• The values for properties inherited from the supertype are stored in the
tables corresponding to the super types i.e. <supertype>_s and
<supertype>_r
• An objects meta-data is spread over several tables joined by r_object_id
of the object
– <type>_s, <type>_r
– <supertype>_s., <supertype>_r
– dm_document_s
– dm_sysobject_s, dm_sysobject_r
– dmi_object_type – this type allows the server to understand
the type of the object based on the r_object_id
– dmr_content_s, dmr_content_r - this is the content
associated with the object.
Option 1 – Object Type Hierarchy ( Database Model)

9 November 2022
Option 1 – Object Type Hierarchy ( Database Model
contd….)
dm_sysobject_s & _r dmr_content_s & _r
<Custom_type>_s & _r
dm_document
dmi_object_type
An Object’s metadata is spread over several tables joined by r_object_id

9 November 2022
• By Default , a property is qualifiable . To define a property as Non-
Qualifiable , use the NON QUALIFIABLE clause while creating the
property.
• The purpose of the non-qualifiable properties is to optimize the retrieval
of multiple property values .Using this the values are stored in
dm_sysobject tables and does not require joining with custom object
type, thus increasing the performance for FETCH statements.
• Non-Qualifiable properties are stored in the i_property_bag attribute of
dm_sysobject
– The r_property_bag repeating attribute stores any overflow from i_property_bag
– Attributes and values are stored in a serialized format
– Do not have designated columns in the database
• Non- Qualifiable properties can be referenced in queries as follows :
– Can be referenced in the SELECT statements in the select values list
– Cannot be referenced in any expression
– Cannot appear in conditional statements of a WHERE clause , unless its an FTDQL
Query
Option 1 – Object Type Hierarchy ( Non-Qualifiable
Properties)

9 November 2022
• Attribute Names should be meaningful according to their purpose
• Avoid single word names such as client
• Minimize the level of hierarchy for object types.
• If attributes required for a selective query are spread over multiple types,
it can effect the query performance .So the attributes which are used
together frequently in queries should be placed in the same object type
• While designing query for objects , make sure that query yield as less
results as possible rather than fetching results and then finding the
desired record
Option 1 – Object Type Hierarchy ( Design
Recommendations)

9 November 2022
• Registered tables can be used to store content-less data.
• Registered tables are RDBMS tables that are not part of the
repository but are known to Content Server. They can reside
in the same database schema as Documentum tables or
separate
• They are represented in the repository by objects of type
dm_registered.
• To use registered tables, they should exist in a database . To
help content server recognize them DQL REGISTER statement
is used.
• After an RDBMS table is registered with the server, you can
use DQL statements to query the information in the table or
to add information to the table.
Option 2 – Registered Tables

9 November 2022
• The data in the registered table can be manipulated (added/
modified/deleted) using DQL as well as SQL commands
• Example of Registered Table use:
– The document metadata might require data values from an external
system. Example for a contract document , client details might need
to be stored as metadata, whereas the client details might be
managed in another system. This data can be brought into
Documentum using ETL tools / web services etc and can be stored in
a registered table. This data can be queried using DQL statements.
Option 2 – Registered Tables (contd …)

9 November 2022
• Aspects is a mechanism for adding the behavior and/or attributes to a
Documentum object instance without changing its type definition
• Aspects allow custom attribute and behavior to be added across many
object types
• Using aspects, the custom attributes can be added to the object type only
when a particular set of conditions apply.
• One object instance can have multiple aspects.
• Aspects are of type dmc_aspect_type
• Example of aspect use:
– Objects need certain attributes and behavior only under certain condition. For
example, a document in review state of its lifecycle has a review_due_date attribute
that indicates the date by which the review is expected to be complete. Once the
review is complete , “review_due_date” is no longer needed and does not need to be
persisted with the object. Using aspects we can attach the review_aspect when the
document enters the Review lifecycle state and can be detached once the document
moves from review to approved state
Option 3 – Aspects

9 November 2022
• Like the object model hierarchy , for each Aspect two tables
are created
– <aspect>_attr_type_s - single attribute
– <aspect>_attr_type_r - repeating attribute
• If attributes required to make a selective query span across
the base type and aspect types, it is better not to use an
Aspect as the database
• Using fetch optimization the aspect properties and their
values are stored alongside the object
– The aspect properties and value are stored nto the objects property bag.
– OPTMIZEFETCH keyword on ALTER ASPECT statement
– This results in fewer database tables being accessed to fetch the aspect
properties
– This also increases storage cost of maintaining more than one instance of the
attribute value
Option 3 – Aspects ( Database Model contd….)

9 November 2022
Option 3 – Aspects ( Database Model)
<Custom_type>_s & _r
dm_document
dmi_object_type
An Object’s metadata is spread over several tables joined by r_object_id
Aspect_attr_type_s &
_r

9 November 2022
• Lightweight object types are a special type used to minimize
the storage footprint for multiple objects that share the same
system information. A lightweight type is a subtype of its
shareable type.
• Shareable object types are the parent types of lightweight
object types. Only dm_sysobject and its subtypes can be
defined as shareable. A single instance of a shareable type
object is shared among many lightweight objects.
• Lightweight objects are useful if you have a large number of
attribute values that are identical for a group of objects. This
redundant information can be shared among the LWSOs from
a single copy of the shared parent object
Option 4 – Lightweight & Shareable Objects

9 November 2022
• A lightweight object represents a separation of unique object
data from redundant system/application information .
Example :
– Object specific metadata : contract-id , client etc
– System/Application specific metadata :lifecycle, security, version information,
retention, etc
• The lightweight objects are created as objects of
dm_lightweight type.
• The dm_lightweight type has no tables representing it in the
repository
• In addition to the properties inherited from the
dm_ligtweight and the properties defined for the subtype,
each lightweight object shares the properties of a shareable
type.
Option 4 – Lightweight & Shareable Objects (Contd…)

9 November 2022
• A lightweight object is said to be Unmaterialized till the time all its shared
properties have identical values with other children of the shared parent.
• Since the parent is shared, the change in an attribute would affect all the
children. If the change should only affect one child, that child object
needs to have its own copy of the parent. When a lightweight object has
its own private copy of a parent, we say that the object is materialized.
• Documentum Content Server creates rows in the tables of the shared
type for the object, copying the values of the shared properties into
those rows.
• The lightweight object no longer shares the property values with the
instance of the shared type, but with its own private copy of that shared
object.
• For Example : When a lightweight object is checked out or when the
lifecycle state of the lightweight object is changed, , the object is
materialized
Option 4 – Lightweight & Shareable Objects
(Materialization)

9 November 2022
• Enabling Efficient Database Storage - Lightweight
object type takes up less space in the underlying
RDBMS than a standard type.
• Enable Rapid Ingestion - Importing lightweight
objects into repository is faster then importing
sysobjects
• Lightweight objects are part of the “High Volume
Server” and designed for transactional and archiving
requirements
Option 4 – Benefits of Lightweight Objects

9 November 2022
• Example : Suppose the following shareable and lightweight object types exist in a
repository
• The order_record type shares with customer_record thus the instances of the
order record type will share the values of instances of the customer record object
• By default, the order record instances are unmaterialized
Option 4 – Lightweight Object ( Database Model)
Customer_record
(with a SysObject supertype and
the following properties)
order_record
(Lightweigt object with the
following properties0
cust_name string(32),
cust_addr string(64),
cust_city string(32),
cust_state string(2)
cust_phone string(24)
cust_email string(100)
po_number string(24)
parts_ordered
string(24)REPEATING
delivery_date DATE
billing_date DATE
date_paid DATE

9 November 2022
• Example : Suppose the following shareable and lightweight object types exist in a
repository
• The order_record type shares with customer_record thus the instances of the
order record type will share the values of instances of the customer record object
• By default, the order record instances are unmaterialized
Option 4 – Lightweight Object ( Database Model Contd
….)
Customer_record
(with a SysObject supertype and
the following properties)
order_record
(Lightweigt object with the
following properties0
cust_name string(32),
cust_addr string(64),
cust_city string(32),
cust_state string(2)
cust_phone string(24)
cust_email string(100)
po_number string(24)
parts_ordered
string(24)REPEATING
delivery_date DATE
billing_date DATE
date_paid DATE

9 November 2022
R_object_id Po_number ….. i_sharing_parent
ObjID1 001 ObjIDA
ObjID2 002 ObjIDA
ObjID3 003 ObjIDZ
ObjID4 004 ObjIDA
R_object_id Cust_name …
ObjIDA Adam
ObjIDB Ed
ObjIDY Joe
ObjIDZ James
R_object_id Po_number ….. i_sharing_parent
ObjID1 001 ObjIDA
ObjID2 002 ObjIDA
ObjID3 003 ObjIDZ
ObjID4 004 ObjIDA
R_object_id Cust_name …
ObjIDA Adam
ObjIDB Ed
ObjIDY Joe
ObjIDZ James
ObjIDAA Adam
Shares
Shares
Database storage of unmaterialized lightweight object instances
Option 4 – Lightweight Object ( Database Model Contd ….)
Database storage of materialized lightweight object instances

9 November 2022
Option 4 – Comparison of Lightweight & Full Objects
Feature Lightweight Object Full Object
Retention Shares with Parent Individual Retention
Security Shares with Parent Individual Object Security
Folder Linking Shares with Parent Can be individually linked
Versioning Not Versionable Fully Versionable
Replication Can’t be replicated Full Replication Support
Lifecycle Shares with Parent Individual Lifecycle

9 November 2022
• Higher Level data modeling option built upon Documentum object model
• Structured collection of data
• Created and managed by end users
• Easy to add, change and delete fields dynamically
• Supports more complex filed types than the standard Documentum
types. Example
– Plain text
– AutoNumber
– Traffic Light
– Yes/No
– Choice List
– Date
– Number
• Field Types can also be represented using relationships to other objects
Option 5 – Data Tables

9 November 2022
• A data table is the best option to use
– If the data needs to be maintained in a table format
– If the data is frequently manipulated by the end users
– If the data rows needs security based on groups and roles . Example :
A data row is visible only to a particular group.
– If data rows need to be associated using lifecycle . Example : A data
row might not be published until approved.
Option 5 –Data Tables (Benefits)

9 November 2022
• A data table is comprised of several different objects and
types:
– dmc_datatable – it is a subtype of dm_folder and represents a container of rows
– dmc_datatable_schema – it is a subtype of dm_sysobject and specifies how the table is
constructed from attributes on the row type. The content of an instance of this object is
XML schema i.e. xsd
– dmc_datatable_rows – its is a subtype of dm_sysobject and is the base type for all row
types. It gives rows a name, ACL , lifecycle support etc
– <row_type> – it is subtype of dmc_datatable_rows and represents rows in the
table.Each row in a datatable has an instance of the row type to store the cell values for
the row.
Option 5 – Data Tables (Database Model)

9 November 2022
Option 5 – Data Tables (Database Model Contd …)
• Each time a user creates a new Data table , a new row type (subtype of
dmc_datatable_row) is created.
• Each row in the data table is an instance of a custom subtype of
dmc_datatable_row. Hence a custom row type with then name
datatable_row_xxxxxx (xxxxxx is a uniquely generated string) is created.
• The row may have relations to other objects like dmc_topic( comments),
dm_folder ( attachments) etc
datatable_row_xxxxxx_
s & _r
dmi_object_type
dmc_datatable_row_s

9 November 2022
• An XML Document is a collection of elements and attributes.
• XML can represent relationships (both internal and external), containment and complex metadata
(sequences, unordered lists , typed data etc)
• XML content allows metadata values to be represented within the content itself allowing for a very
dynamic data model
Option 6 – XML Content

9 November 2022
• To manage XML content efficiently in Documentum, XML Store can be used.
• The Documentum XML Store add-on is installed during Content Server installation and requires an
additional license key.
• XML Store/xDB is a highly-scalable, native XML repository for Content Server.It adds standards-based
XQuery to the XML capabilities of Content Server. A native XML content store or repository persists XML
content “as-is,” without mapping the XML to RDBMS rows and columns.
Option 6 – XML Content (xDB)
• The XML structure is preserved, allowing users to
efficiently and accurately query content at any level
of detail (e.g., individual elements, attributes,
content objects, or metadata attributes), even on
very large information sets.
• As a native XML repository, XML Store provides
performance advantages over relational databases
and file systems through specialized XML indexing
methods, caching, and architecture optimized for
XML.
• xDB allows various nodes in an XML to be treated
independently though “Chunking”

9 November 2022
• xDB is a database that enables high-speed storage and can handle an extensive amount of XML
documents. It is based on EMC acquisition of X-Hive XML database.
• Using xDB, programmers can build custom XML content management solutions that are fully tailored to
the exact requirements of any given application.
• xDB stores XML documents in an integrated, highly scalable, high-performance, object-oriented
database. It stores documents in persistent DPM format.
• xDB exposes the database and its contents via an application programming interface (API). The API is
written in Java.
• xDB supports multi-statement transactions and full ACID (Atomicity, Consistency ,Isolation, and
Durability).
• XML Content can be indexed to improve query performance.
• xDB implements and extends the following recommendations of the World Wide Web Consortium
• (W3C) for querying, retrieving, manipulating, and writing XML documents:
Option 6 – XML Content (xDB Cont…)
•Document Object Model (DOM Level 1 •xQuery
•Dom Level 2 9Core and Traversal) •xPath
•DOM Level 3 (Core and Load/Save) •xLink
•The eXtensible Stylesheet Language Transformation (XSLT) •xPointer

9 November 2022
Strengths and Limitations for each model
S
No
Data Model Strengths Limitations Best Use
1 Object Type Hierarchy Fully Supported by All Clients •Larger Database footprint with
large number of objects
•Not dynamic
•Data Model well known in advance
•Static data Model
•Not large amount of archive data
2 Registered tables Simplistic data storage
Easy to maintain data from external
sources
Requires a custom UI to give users
control over the data stored
Admin can modify data through
DQL/SQL queries
As a supporting type for managing
metadata options when the
metadata values are received from
external source
3 Aspects •Can be attached and detached to
and from objects conditionally
•Can span object types
Same as traditional object
hierarchy
•Attributes and/or behavior needed
only in a particular object state
•Attributes and/or behavior span
types
4 Lightweight & Shareable Objects Smallest Database footprints for
large number of objects
Not appropriate when attribute
values cannot be shared
•Large amount of archive data
•High Volume Ingestion
5 Data Tables •Supported by knowledge worked
clients
•Advanced Collaboration column
types supported
Large number of types can be
inadvertently created
•Dynamic user defined types
•Collaboration
6 XML •Excellent performance for large
number of types
•Dynamic Types
Requires a custom client •Dynamic data model
•Existing XML application

9 November 2022 - 32 -
Thank you
Experience Certainty

Documentum Data Models.ppt

More Related Content

What's hot (20)

Similar to Documentum Data Models.ppt (20)

Recently uploaded (20)

Documentum Data Models.ppt

Editor's Notes