I have several questions on CMBD. Thanks for the feedback.
Is CMDB table schema standardized among different implementations? Are CMDB programming APIs standardized? Are there minimal required CI properties that CMDB should contain? Are CI relationship types specified? What about CMDB extensions... is the extension mechanism standardized?
So assume nothing is standardized, otherwise I'd get a reference to a publicly accessible RFC, or at least a draft spec.
If you think of CMDB as an application-specific repository, there must be a set of standards, otherwise it's confusing when a proprietary data store is branded as "CMDB".
What is wrong with CIM as mezanine standard for CMDB? It's got a well defined taxonomy of managed elements - from component level to service level, a dependency model. Think of it, it'd be neat to be able to access/browse/manage OVSD CIs with WMI calls.
OVSD 4.5, until SP 18, had essentially a stable set of schema (although some new custom fields were made available). With SP 18, you gained the ability to extend the custom fields delivered by default with your own "custom fields". Unfortunately, I do not know if the API was adapted to meet this new functionality. This is an important point because the API hard coded the columns.
CI relation types are of one standard type (parent-child) and of two freely defined types:
1) CI relations that existed all along in 4.5 (and in 5.0, I suppose). The relation type is merely a code value. You can create any relation types you wish, used to relate any two CIs. There is no logic built in to this relation type (unlike the parent-child, which forbids more parent-child relations than the max. number defined for the non-unique child.
2) Generic relations, that are delivered in SP17 and which allow you to relate any two types of items (not just CIs to CIs). No generic relations are specified by default.
Thanks. Not clear from your post whether OVSD's CMDB supports definition of multiple parent CIs for each child CI. If that's the case, the constraint is probably implemented in app. code, because the ITSM_CI_RELATIONS lookup table does not seems to implement any integrity constraints (other than FK to CI oids).
CI relations and CI parent/child relations are not modeled in the same way in the database. Only CI relations are modeled in ITSM_CI_RELATIONS. If there are any constraints on that table, they are not relevant to Parent-Child. Parent-Child relations are modeled in ITSM_CICOMPONENTS. I have never bothered to look if there is a constraint there. In any case, the application logic handles the number of parents.
The number of parents is only limited by the max. number for the non-unique CI child.