close

What Is Truth to Power?

dedicated to bridging the gaps between governance and practice, technology and business, regulation and control, risk management and real market pressures, and your own knowledge and the knowledge of your peers.
built to create a common pool of knowledge—one big brain—that lets you work more efficiently, build technology and business practices more effectively, and endure audits more effortlessly.
a neutral hub through which you can reach many valuable information nodes, resource collections, and organizations that are helping people like you already, but in fractured ways.
against the idea that auditors, analysts, and consultancies can control information simply through their ability to collect and distill it. T2P's goal is to unlock the vast body of knowledge, insight, and conventional wisdom that we all have, make it freely available to you, and help you digest and interpret it—without undue cost, bias, or hype.
Top Panel
WHAT IS T2P?
Top Panel

Expert Core: Semantics

dennis_davidson_3_cg.jpgCore Guide Dennis Davidson taps more than 30 years of experience in strategic and technical management to clarify the nature, uses, and value of semantics in enterprise information governance.
[ More about Dennis... ]



Enterprise Repositories

An enterprise repository stores complex objects engaged in complex relationships. Unlike most databases, which are designed for simple, highly structured records engaged in fairly simple relationships with other records, repositories must be able to support:

  • Complex objects
  • Bi-directional, many-to-many relationships
  • Deep inheritance
  • Recursion
  • Rich versioning
  • Extensible metamodels

Interestingly, many so-called repositories are implemented with conventional database technology, which typically does not support all of these requirements. When vendors use conventional database technology for applications requiring these advanced features, they’re pushing the envelope.  This is something to be aware of when you're evaluating repository solutions.

By conventional database technologies, I primarily mean relational and object-oriented. Also included, however, are less common (these days) database technologies, such as hierarchical, network and multi-value.  Relational databases, for example, while very flexible don’t scale well when too many runtime joins are required to assemble complex objects. Object oriented databases overcome some but not all of the limitations of relational databases. The relative capabilities and limitations of both types of databases are summarized in the following table:

 
 Capability  Relational Databases  Object Oriented Databases
Treats Configuration Items (CI) as non-flat objects  No  Yes
Supports complex data structures  No  Yes
Represents arbitrarily complex, non-uniform data structures  No  No
Supports complex relationships  No  No
Metadata organized based on a flexible, extensible metamodel  No  No
Includes relationship logic inside the database  No  Yes
Can handle undefined CIs  No  No
Structural changes are easy  No  No
 

Configuration Items (CI) refers to the contents of a Configuration Management DataBase (CMDB), which provides a convenient frame of reference for defining repository requirements since CIs can be complex and engage in complex relationships.  We can see from this table that, even with object oriented databases, there are limitations.

There is actually a relatively unknown class of database technology addresses the limitations noted above. That class is a topic for a future posting.

 

 

Recommended Resources