Skip to main content

Core Concepts

Understanding a few core concepts of the CMDB system will help you quickly master the use of Huayang CMDB.

Three Elements of the Data Model​

The CMDB data model is built around three core entities:

Configuration Item (CI) is the basic data unit managed by CMDB, representing any IT asset that needs to be managed — servers, applications, databases, network devices, etc. Each CI is a specific instance of a CI Type, possessing a set of attribute values defined by that type.

CI Type defines the "blueprint" of a CI — which attributes it contains, the types and constraints of attributes, how to identify duplicates (identification rules), and which types can establish relationships with it. Types support inheritance, with subtypes automatically gaining the attribute and relationship definitions of their parent types.

Relationship describes the connections between CIs. Relationships can be established between two CIs (e.g., "an application runs on a server"), and the kinds of relationships are defined by Relationship Types, while which types are allowed to establish relationships is constrained by Valid Links.

These three elements form the data foundation of CMDB: types define the data structure, CIs carry the data, and relationships connect the data. All functional modules of CMDB revolve around these three elements.

For specific term definitions, see the Glossary.

Module Concepts​

The features of Huayang CMDB are organized by modules, each responsible for a clearly defined management domain. Understanding the positioning of each module helps you understand the overall operation of the system.

Data Modeling Layer​

The following three modules together constitute the data model definition capabilities of Huayang CMDB.

CI Type Management​

CI Type is the foundation of the CMDB data model. This module is used to define and manage all CI types — including basic type information, attribute structure, identification rules, and relationship configuration.

From a system perspective, CI types define the schema of the entire CMDB: the data structure of all CI instances is determined by type definitions. Types support inheritance, forming a hierarchical structure (e.g., Host → Computer → Linux), where subtypes inherit the attributes and relationship definitions of their parent types while adding their own attributes.

The core configurations of this module include:

  • Attribute Management: Define which fields, field types, and validation rules the CIs of this type possess
  • Identification Rules: Define how to determine whether two pieces of data represent the same CI during auto-discovery, used for data merging and deduplication
  • Valid Links: Constrain which other types this type can establish relationships with and what kind of relationships

Relationship Type Management​

Relationship types define what kinds of connections can be established between CIs. The relationship type itself is a generic definition, and Valid Links further constrain "which types can use which relationship types" in the CI type configuration — together, they form the complete relationship constraint system.

Option List Management​

Option lists provide predefined sets of selectable values for CI attributes (e.g., Service Type includes External and Internal options), ensuring consistency and standardization of attribute values. Option lists are a fundamental component in type attribute definitions.

Data Access Layer​

The following two modules are the two main entry points for users to access and browse CI data.

CI Directory​

CI Directory is the entry point for browsing CIs by type hierarchy. The left side displays the hierarchical structure of all CI types as a type tree, while the right side shows the CI instance list of the selected type, with columns dynamically generated based on type attributes.

It provides full lifecycle management capabilities for CIs: view details, edit attributes, manage relationships, view topology and change history. The detail page organizes information across different dimensions through multiple tabs (Details, Dependencies, Components, History).

CI List​

CI List is a feature for quickly accessing specific sets of CIs based on predefined query conditions. Users can create custom list views, specifying root CI types and filter conditions, which can be saved and reused.

Unlike the "browse by type" approach of CI Directory, CI List is more like "saved queries," suitable for scenarios where you need to frequently view CIs matching specific conditions.

The system comes with a rich set of out-of-the-box common CI lists. Users can also create or clone from existing system lists to suit their own needs. Compared to CI Directory, CI List is easier to understand and more suitable for general users.

Data Analysis Layer​

Query Studio​

Query Studio is used to build and manage Topology Queries. Topology Query Language is the CMDB's query language, capable of cross-type querying of CIs and their relationship data.

Query Studio visualizes queries: users build query graphs with CI types as nodes and relationships as connections, configure filter conditions and return attributes, without writing query statements manually. Built query definitions can be saved and reused, and are also an important data source for dashboard widgets.

Dashboard​

Dashboards display CMDB data through visual widgets, providing operational insights from a global perspective. Each dashboard consists of multiple widgets, and the data sources for widgets can be TQL query results or CI statistics.

Dashboards support both view and edit modes. System preset dashboards cannot be modified, but users can create custom dashboards for personalized monitoring.

Relationships Between Modules​

The modules form a clear data flow within the CMDB:

First, define types and relationship structures in the data modeling layer, then enter and manage CI instances based on these types, and finally analyze and visualize the data through queries and dashboards.