CMDB Data Model Design Pattern for…

advancedTested on Xanadu

The CMDB Data Model Design Pattern provides a structured approach to building a Configuration Management Database that accurately represents your IT infrastructure and business services. This pattern focuses on creating a logical hierarchy of Configuration Item (CI) classes, establishing meaningful relationships between CIs, and implementing data governance through source precedence and normalization rules.

The core challenge in CMDB design is balancing completeness with maintainability while ensuring the model serves actual business use cases like impact analysis, change planning, and service mapping. A well-designed CMDB model uses inheritance effectively, avoids redundant CI classes, and establishes clear data ownership patterns that prevent conflicts between multiple data sources.

This pattern works by defining a base CI class structure that mirrors your organization's technology stack, implementing relationship rules that capture dependencies and ownership, and establishing data source authority hierarchies that ensure data quality and consistency over time.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when implementing a new CMDB, redesigning an existing one that has grown organically, or when you need to integrate multiple data sources into a unified configuration model. This is essential for organizations that require accurate impact analysis, automated service mapping, or comprehensive change risk assessment.

Avoid When

Avoid this pattern if your organization lacks the governance structure to maintain CMDB data quality or if you're building a simple asset tracking system that doesn't require relationship modeling. This approach requires significant upfront planning and ongoing maintenance that may not be justified for small organizations with minimal IT infrastructure complexity.

Implementation

Server-side

var CMDBModelManager = Class.create();
CMDBModelManager.prototype = {
    initialize: function() {
        this.sourceHierarchy = {
            'manual': 10,
            'discovery': 20,
            'orchestration': 30,
            'integration': 40
        };
    },

    // Create CI class with proper inheritance and attributes
    createCIClass: function(className, parentClass, attributes) {
        var gr = new GlideRecord('sys_db_object');
        gr.initialize();
        gr.name = className;
        gr.super_class = parentClass || 'cmdb_ci';
        gr.label = attributes.label || className;
        gr.is_extendable = attributes.extendable || false;
        var sysId = gr.insert();
        
        // Add custom attributes
        if (attributes.fields) {
            for (var field in attributes.fields) {
                this._createField(sysId, field, attributes.fields[field]);
            }
        }
        
        gs.info('Created CI class: ' + className + ' extending ' + (parentClass || 'cmdb_ci'));
        return sysId;
    },

    // Define relationship between CI classes
    createRelationshipType: function(parentType, childType, relationshipType) {
        var gr = new GlideRecord('cmdb_rel_type');
        if (gr.get('name', relationshipType)) {
            return gr.getUniqueValue();
        }
        
        gr.initialize();
        gr.name = relationshipType;
        gr.parent_descriptor = 'Contains';
        gr.child_descriptor = 'Contained by';
        var relTypeId = gr.insert();
        
        // Create type rule for this relationship
        var ruleGr = new GlideRecord('cmdb_rel_type_rule');
        ruleGr.initialize();
        ruleGr.parent_class = parentType;
        ruleGr.child_class = childType;
        ruleGr.rel_type = relTypeId;
        ruleGr.insert();
        
        gs.info('Created relationship type: ' + relationshipType);
        return relTypeId;
    },

    // Set data source precedence for CI attributes
    setSourcePrecedence: function(ciClass, fieldName, sourceRules) {
        var gr = new GlideRecord('cmdb_source_precedence');
        gr.addQuery('ci_class', ciClass);
        gr.addQuery('field_name', fieldName);
        gr.query();
        
        // Remove existing rules
        while (gr.next()) {
            gr.deleteRecord();
        }
        
        // Add new precedence rules
        for (var i = 0; i < sourceRules.length; i++) {
            var rule = new GlideRecord('cmdb_source_precedence');
            rule.initialize();
            rule.ci_class = ciClass;
            rule.field_name = fieldName;
            rule.source = sourceRules[i].source;
            rule.precedence = sourceRules[i].precedence;
            rule.condition = sourceRules[i].condition || '';
            rule.insert();
        }
        
        gs.info('Set source precedence for ' + ciClass + '.' + fieldName);
    },

    // Normalize CI data based on business rules
    normalizeCIData: function(ciSysId) {
        var ci = new GlideRecord('cmdb_ci');
        if (!ci.get(ciSysId)) {
            return false;
        }
        
        // Apply naming convention normalization
        if (ci.name) {
            ci.name = ci.name.toString().toLowerCase().trim();
        }
        
        // Set operational status based on install status
        if (ci.install_status == '1' && ci.operational_status != '1') {
            ci.operational_status = '1'; // Operational
        }
        
        // Ensure environment classification
        if (!ci.environment && ci.name.toString().indexOf('prod') >= 0) {
            ci.environment = 'production';
        }
        
        ci.update();
        return true;
    },

    // Validate CMDB model health
    validateModelHealth: function() {
        var issues = [];
        
        // Check for orphaned CIs
        var orphanGr = new GlideAggregate('cmdb_ci');
        orphanGr.addQuery('cmdb_rel_ci_outbound', 'ISEMPTY');
        orphanGr.addQuery('cmdb_rel_ci_inbound', 'ISEMPTY');
        orphanGr.addAggregate('COUNT');
        orphanGr.query();
        
        if (orphanGr.next() && orphanGr.getAggregate('COUNT') > 0) {
            issues.push('Found ' + orphanGr.getAggregate('COUNT') + ' orphaned CIs');
        }
        
        // Check for duplicate CIs by name and class
        var dupGr = new GlideAggregate('cmdb_ci');
        dupGr.groupBy('name');
        dupGr.groupBy('sys_class_name');
        dupGr.addHaving('COUNT', '>', 1);
        dupGr.query();
        
        var duplicates = 0;
        while (dupGr.next()) {
            duplicates++;
        }
        
        if (duplicates > 0) {
            issues.push('Found ' + duplicates + ' potential duplicate CI groups');
        }
        
        return issues;
    },

    _createField: function(tableId, fieldName, fieldConfig) {
        var field = new GlideRecord('sys_dictionary');
        field.initialize();
        field.name = tableId;
        field.column_label = fieldConfig.label;
        field.element = fieldName;
        field.internal_type = fieldConfig.type || 'string';
        field.max_length = fieldConfig.length || 40;
        field.mandatory = fieldConfig.mandatory || false;
        field.insert();
    },

    type: 'CMDBModelManager'
};

This code demonstrates a comprehensive CMDB model management approach including CI class creation with proper inheritance, relationship type definition with rules, and data source precedence configuration. The validateModelHealth method provides ongoing model quality assessment by identifying orphaned CIs and potential duplicates, while the normalizeCIData method ensures consistent data formatting and business rule application.

Alternatives

Discovery-Driven Model

Build the CMDB model based on what Discovery finds rather than designing upfront. This is faster to implement but can result in a fragmented model that doesn't align well with business services and may require significant cleanup later.

Service-Centric Model

Design the CMDB around business services first, then map technical components underneath. This approach better supports service management use cases but requires strong business-IT alignment and may struggle with infrastructure components that span multiple services.

Federated CMDB Approach

Keep authoritative data in source systems and federate views into ServiceNow rather than centralizing all CI data. This reduces data synchronization complexity but limits offline analysis capabilities and may impact performance for relationship queries.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue