Relationships in xCP2 – Part 1 November 7, 2012

I have had a great opportunity to spend time with the new xCPDesigner, the product that brings together in one UI all of the design tasks required to create an xCP2 application. Over the next several weeks I plan on walking you through what I see as the most significant features – in other words – the stuff I think is cool.

With so much to talk about though – where should I start? Anyone who is married or worked with Documemtum will tell you relationships are hard. The difference is I understand the relationships in Documentum so that is what I will write about first.

I have long believed that one of the greatest powers in Documentum is the variety of ways you can model relationships. Metadata on documents and folders is useful but how we give the user easy ways to view and manage related objects (structured and unstructured) evolves it beyond content management and into something much richer.

Long time Documentum architects need to understand that xCP2 introduces many new design concepts but relationships integrated into information modeling as a “first-class” activity transforms your approach to most everything that follows. Before I go into how xCP2 does this it may be useful to describe how we have accomplished this in the past.

In my experience there are three ways to think about modeling relationships in Documentum. In terms of containment, direct referencing, and abstracted referencing.

Containment as the name implies is based on a parent/child, 1 to many model. Most often this is implemented in folder structures with the folder as the parent and all objects linked to that location are children. This is the simplest model and the foundation for hierarchical navigation in all WDK user interfaces. The fact that navigationally a single object can be linked to many locations (think symbolic links) has long been a powerful differentiator.

Direct referencing relies on attributes in the data model of one type that are populated with data that identifies a target child or parent object. (think foreign keys) This method is generally the most efficient because it requires fewer joins to visualize the connected objects in a single view. From a product perspective however direct referencing is not as flexible because of its dependence on custom DQL. This is the way most developers have created custom relationships largely because of the degree of control it gives the developer and incidentally is productized in many constructs (e.g. virtual documents). Even though DQL and various API’s make it possible to manage these structures, the user interfaces have never made it easy to leverage. Consequently developers over the years have sacrificed data normalization/efficiency for convenience and overlayed folders on top of the referenced metadata simply because it was easier to consume in the UI.

Abstracted referencing makes use of a relationship type object (dm_relation_type) to define the linkage between two objects and an instance of a dm_relation to persist it. It further models relationship types so that multiple relationships between the same object can be easily constructed. Relationships are qualified from parent to child and include referential integrity checks and other features.

This last mechanism has always been the “right way” to model the construct for me but the API and UI have never made it easy. Traversing these connections required complex joins and UI customizations that often exceeded the benefits of this more elegant design.

Until now…

more in Part 2.