Demystifying the CMDB

I would suggest the following reading (all available on line) by Andrew Conry-Murray

http://www.itarchitect.com/shared/ar...leId=166400731

(A short clearly written summary of some of the challenges, and the (almost) current state of play. - Note Andrew's reference to the CIM standard 'Common Information Model' by the Data Management Task Force. If you are serious about designing a meta-data schema for a CMDB - don't! The CIM has every attribute and relationship you are likely to need for a long time already defined and documented. But not for the faint-hearted )

The primary objective of your CMDB should be that it shows the dependencies of the components of your infrastructure. Relationship attributes are more important than descriptive ones. But not just any realtionships - the final result should show each CI as a production factor of the Services you provide.

To this end the ITIL Service Level Management chapter recommends recording your Services in CIs in your CMDB. These should be the top level of the CMDB, and everything else mapped into them. To do this you will need to effectively define classify and model your services. To that end I recommend you look for a Pink Elephant whitepaper called:

 Defining, Modeling & Costing IT Services (Integrating Service Level, Configuration & Financial Management Processes)

Which is a good run up to how the real value of the CMDB lies in cordinating it with a simple service definition and classification model. Which would provide the meta-data schema for classifying Service CI attributes.

Which brings me to the final point. The CMDB is more than a collection of CIs with status attributes attached. It is a management tool and as such many of the structures that should be contained in it are actually 'arbitrary' collections of components that need to be controlled as 'systems' or 'applications' and etc. This means the CMDB has to be able to represent the infrastructure through more than one abstract model. (I recommend, component, system, and service layers). An upshot of this is that different 'kinds' of CI's will be necessary, (and not just to cover the differences between hardware, software and documentation), and with that different attributes. This means a normalised relational DB may not be the most effective representation. Expect a functioning CDMB to push RDBMS implementation to its limits.

But not to ignore you post, and to get back to the point, try and find:

Modeling the IT Enterprise Infrastructure An IT Service Management Approach by David Chui and D. L. Tsui