- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-21-2022 07:53 AM
Hi Team,
I am looking for suggestion on ServiceNow recommended data model for Databases.
One of our client uses - Oracle, SQL and Sybase Database.
We have designed SQL Database to have two layers (MS SQL Instances and MS SQL Database). While for Sybase and Oracle, DBs are stored under Database Instances.
We are planning to normalize this model to have the same structure for all 3 DBs.
To add, we haven't enabled discovery for the Databases. At the moment, we are manually importing them via loaders.
I would like to understand from the CMDB Architects on how they implemented Data model for DBs.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2023 02:19 AM
Hi Rajesh,
If you plan to manually maintain (or import) Databases, then I would recommend a model where Database records are related to Application Services upstream and Database Instances downstream.
I'm not sure what additional value comes from using tech-specific CI classes, especially if this information is available via other attributes (like Type on cmdb_ci_database), so I would keep the model simple and use the parent classes for Database (cmdb_ci_database) and Database Instance (cmdb_ci_db_instance) or maybe replace Database class with a Database Catalog (cmdb_ci_db_catalog), like here:
Cheers,
--Mikko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-21-2022 08:08 AM
Hello Rajesh,
I would say that even if ServiceNow recommends to populate the cmdb_ci_appl table using Discovery or other integrations, you can use the existing tables for storing the two objects you mentioned:
MS SQL Database in table cmdb_ci_db_mssql_database
MS SQL Instance in table cmdb_ci_db_mssql_instance
You will have a relationship of type Contains::Contained by between the instance and the database
And of course you can have a relationship of type Runs:Runs on between the database and the server just to keep it simple and manageable.
Hope it helps.
All the best,
Mihai

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2023 02:19 AM
Hi Rajesh,
If you plan to manually maintain (or import) Databases, then I would recommend a model where Database records are related to Application Services upstream and Database Instances downstream.
I'm not sure what additional value comes from using tech-specific CI classes, especially if this information is available via other attributes (like Type on cmdb_ci_database), so I would keep the model simple and use the parent classes for Database (cmdb_ci_database) and Database Instance (cmdb_ci_db_instance) or maybe replace Database class with a Database Catalog (cmdb_ci_db_catalog), like here:
Cheers,
--Mikko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-04-2025 08:37 AM
I got confused by different sources of information. We want to keep our named databases. I understand discovery won't find them, but will find instances. The way I read this article is that is ok. If there is additional things I need to look at let me know. Thank you.