OOTHUB Blog Detail

OpenText Content Server’s database schema is built on a robust and intricate entity-relationship model. At its core, a few foundational principles govern how data is structured and accessed. Once these are understood, the logic behind the entire system becomes much clearer.

 

Core Tables: DTreeCore vs. DTree

One of the first distinctions developers must grasp is between DTreeCore and DTree:

1. DTreeCore is the primary table that stores one record for every item in Content Server—documents, folders, workflow maps, and more.
2. DTree is typically a view built on DTreeCore, offering backward compatibility and simplified access.
   
   

Key Characteristics of DTreeCore:

• Single Source of Truth: Each object has exactly one record.
• Polymorphic Design: Supports multiple object types with a shared structure.
• Extensibility: The ExtendedData column allows for custom object data storage.
  
  

Understanding when you're querying the view versus the base table is essential for performance tuning.

 

Document Lifecycle: The Four-Table Chain

The document lifecycle in Content Server is elegantly modeled through a four-table relationship:

DTreeCore (1) → DVersData (1:many) → ProviderData (1:1) → BLOBData (1:many)

Table Roles:

• DTreeCore: Establishes item identity.
• DVersData: Manages version history.
• ProviderData: Determines storage location (internal/external).
• BLOBData: Stores binary content for internally managed files.
  
  

This structure supports:

• Efficient versioning
• Flexible storage strategies
• Granular access control
  
  

Multilingual Metadata: DTreeMultilingual

To support internationalization, Content Server uses the DTreeMultilingual table:

• Stores language-specific metadata separately from DTreeCore.
• Uses DataID and language code as keys.
  
  

Design Insight:

This normalized approach avoids bloating the core table with language-specific columns, though it requires joins for multilingual queries.

---

Security Model: DTreeACL and Permission Management

The DTreeACL table implements a sparse matrix for access control:

• No record for items using default permissions (Owner, Group, Public).
• One record per exception for explicit grants or denials.
• Bitmask-based permissions for efficient evaluation.

Performance Note:

Sparse design is efficient for default permissions but can be costly for complex ACLs.

---

Audit Trail: DauditNew

The DauditNew table captures audit events:

• One record per action.
• Links to both the item (DataID) and the user (PerformerID).
• Populated based on audit settings.

The “New” suffix reflects its evolution from an earlier audit table.

---

User Identity: KUAF and KUAFChildren

KUAF is the central identity store for users, groups, and domains:

• Links to content ownership (DTree, DVersData), permissions (DTreeACL), audit logs (DauditNew), workflows, and notifications.

KUAFChildren manages group memberships:

KUAF (groups) ←→ KUAFChildren ←→ KUAF (users)

Supports nested groups and efficient expansion algorithms.

---

Workflow Engine: Definition vs. Execution

Content Server separates workflow definition from execution:

• WMap / WMapTask: Define workflows and steps.
• WWork / WSubWorkTask: Track runtime state.
• WWorkAudit: Logs workflow actions.
• WFATTRData: This table stores the actual values of workflow attributes

Todo View:

Aggregates active tasks using joins, providing real-time visibility without redundant storage.

---

Category System: Metadata Storage Strategies

Two tables manage category attributes:

• LLAttrBLOBData: Stores full attribute sets as BLOBs—compact but hard to query.
• LLAttrData: Stores individual attributes—optimized for querying but duplicates data.

CatRegionMap links categories to search index regions for efficient full-text search.

---

Configuration Management: Transition to Kini

The Kini table replaces file-based configuration (opentext.ini) with database-driven settings:

Benefits:

• Cluster-wide consistency
• Runtime updates
• Versioning and audit trails
• Reduced file system dependency

This shift reflects Content Server’s architectural evolution.

---

Performance Optimization: Schema-Aware Strategies

Join Patterns:

• Hot Paths: Frequent joins like DTreeCore → DVersData
• Cold Paths: Less frequent but expensive joins (e.g., multilingual, audit)
• ACL Evaluation: Performance varies with ACL complexity

Indexing:

• Primary keys on ID columns
• Foreign key indexes for navigation
• Specialized indexes for common queries

The Read-Only Rule: Protecting Data Integrity

Important Note: While a deep understanding of Content Server’s schema is invaluable, it’s critical to avoid making direct database writes outside of the official Content Server APIs. The relationships between tables are governed by complex business logic that is not enforced at the database level, and bypassing these constraints can lead to serious data corruption and system instability.

---

Practical Applications of Schema Knowledge

Mastering the entity-relationship architecture of Content Server empowers developers and administrators in several key areas:

• Performance Optimization: Identify costly join patterns and improve query efficiency.
• Integration Development: Design robust data extraction and synchronization workflows.
• Capacity Planning: Analyze storage growth trends across related tables.

Troubleshooting: Diagnose data integrity issues and resolve relationship inconsistencies.