Not sure I fully understand the question but I will provide whatever I can.
CSDM does not actually address Database Instance or Database Catalog CIs directly, but both of them should ultimately roll up to the Application Service CI, and that's where CSDM starts to provide guidance.
From what I understand, you are looking to represent the fact that some portions of the database schema are used for one Application Service, and other portions would be for a different Application Service. Is that right?
Logically speaking, where the catalog diverges is most likely at the Information Object level, as this is where different Information/Data stored in the database can be used by different Applications. But once we get to the Information Object level, we are (most likely) not talking about specific deployed instances of the Business Application, but the Business Application itself. According to CSDM, the Business Application is defined according to the Information Objects that it uses. Note that if a Business Application uses an Information Object (let's say "Email Address") then this implies that all deployed instances of that Business Application (i.e. the Application Services) will have dependencies on the specific physical data objects stored in the Database Catalog, but the bottom line here is that these relationships are not typically tracked in the CMDB. It is unlikely that you will have the actual physical data objects stored as Information CIs, but if you did, they would only roll up to the Business Application, not the Application Services.
Put another way: because Information Objects are part of the Design domain, not the Manage Technical Services domain, neither CSDM nor the default Discovery patterns would provide you visibility into specific data element dependencies that roll up to an Application Service or Offering. Rather, the only thing that would be in the bounds of an Application Service in this case would be the specific Database Instance itself.
As for the Database CI class I am not aware of any Discovery patterns or third party integrations that result in the creation or update of Databases, so I'm not sure where they would sit except that they would probably roll up to Technical Services.
Below is an example. As you can see here, the structure of the database is only exposed at the Application (enterprise architecture) level, not at the Service level.
I hope this is helpful. If so please mark it as Helpful and/or click Accept Solution if this has sufficiently answered your question.
Not sure I fully understand the question but I will provide whatever I can.
CSDM does not actually address Database Instance or Database Catalog CIs directly, but both of them should ultimately roll up to the Application Service CI, and that's where CSDM starts to provide guidance.
From what I understand, you are looking to represent the fact that some portions of the database schema are used for one Application Service, and other portions would be for a different Application Service. Is that right?
Logically speaking, where the catalog diverges is most likely at the Information Object level, as this is where different Information/Data stored in the database can be used by different Applications. But once we get to the Information Object level, we are (most likely) not talking about specific deployed instances of the Business Application, but the Business Application itself. According to CSDM, the Business Application is defined according to the Information Objects that it uses. Note that if a Business Application uses an Information Object (let's say "Email Address") then this implies that all deployed instances of that Business Application (i.e. the Application Services) will have dependencies on the specific physical data objects stored in the Database Catalog, but the bottom line here is that these relationships are not typically tracked in the CMDB. It is unlikely that you will have the actual physical data objects stored as Information CIs, but if you did, they would only roll up to the Business Application, not the Application Services.
Put another way: because Information Objects are part of the Design domain, not the Manage Technical Services domain, neither CSDM nor the default Discovery patterns would provide you visibility into specific data element dependencies that roll up to an Application Service or Offering. Rather, the only thing that would be in the bounds of an Application Service in this case would be the specific Database Instance itself.
As for the Database CI class I am not aware of any Discovery patterns or third party integrations that result in the creation or update of Databases, so I'm not sure where they would sit except that they would probably roll up to Technical Services.
Below is an example. As you can see here, the structure of the database is only exposed at the Application (enterprise architecture) level, not at the Service level.
I hope this is helpful. If so please mark it as Helpful and/or click Accept Solution if this has sufficiently answered your question.
