Posted: Fri Dec 28, 2007 10:51 pm Post subject: Relationship
We have CMDB and we have defined relationship between CI's as an attribute of CI's and not as a CI. In my opinion relationship is an attribute of a CI but people in my company think we should make relationship a CI. I am trying to find out what other companies have done in terms of relationship
I to date have not seen in my previous or current organization having the relationship as a CI. we have always managed this as an attribute to the CI itself. From the tools i have worked with this seemed to be standard in the core functionality.
If you try to draw out what those in your company or thinking it should be you may be able to demonstrate why this is an additional overhead and unnecessary step.
Simple Example1 - CI's - SwitchA, SwitchB, RelationshipX. An attribute of SwitchA will link to RelationshipX. An Attribute of RelationshipX will link to SwitchB. RelationshipX will just simply contains details of the relationship.
Example2 - CI's - SwitchA, SwitchB. An attribute of switch A will link to SwitchB with a descriptor of(depends on, part of, feeds to etc). This is as simple as you need to go and the descriptors will depend on your organization(if you went out of the box or customized with your own). This is also as i have seen core functionality out of many tool sets.
Now when looking at the two examples when you present them, what is the value add that example1 is providing(as this example seems to mimic the situation you described)? What is the reason they are wanting to goto this model and how can it be effectively and efficiently managed? _________________ Adam
Practitioner - Release and Control
"Not every change is an improvement, but every improvement requires a change"
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Thu Jan 03, 2008 5:54 am Post subject:
ARoll summed it up perfectly. Take his/her question
"Now when looking at the two examples when you present them, what is the value add that example1 is providing(as this example seems to mimic the situation you described)? What is the reason they are wanting to goto this model and how can it be effectively and efficiently managed?:"
and bring it to the people who want to define a relationship as a CI. I bet you they won't have a good answer for you
My point is that there is no right or wrong as long as their is a reason for doing something certain way. A justified reason.
In a lot of companies people are simply afraid to ask the "Why" question.
Joined: Mar 03, 2007 Posts: 33 Location: Minneapolis
Posted: Mon Jan 14, 2008 1:22 pm Post subject: basic data modeling
Relationships are not attributes. Please check out a book on basic data modeling. There are three primary elements to a data model: entity, attribute, and relationship. This is not something that changes with a "CMDB," which is just a particular kind of database.
Relationships *can* take on aspects of entities (e.g. CIs). Search on "intersection entity." This can be a tricky area.
There is no substitute for a firm grounding in data or object class modeling for anyone trying to make sense of a CMDB. All of these questions are covered in Data Modeling 101.
Keywords: E/R modeling, relational model, data modeling, data architecture, metamodeling.
You are right.. and potentially wrong with CI relationships as attributes.
If you can only have one dependency then a CI could have an attribute to make it easy to manage. Example the OS on a server could be an attribute, so could the model. In fact many people use spreadsheets as a "cmdb" with the columns representing a dependency.
But... If there is more than one potential dependency then an attribute doesn't work because you need a relational database approach - called a CMDB. So a server can have multiple Applications - must use CIs. A server may deliver multiple services - must use CIs. A server may have multiple IP addresses so a single attribute field won't work.
A major problem with using CIs is that you then have difficulty with reporting as you often have to build custom queries to get data out, and validating becomes a problem
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum