Table extension and classes

Release version: Xanadu

Updated August 1, 2024

4 minutes to read

Summarize

Summarized using AI

Summary of Table extension and classes

Table extension in ServiceNow allows administrators and application developers to create child tables that share fields and records with a parent table. This feature is used to organize related records that share common information by establishing parent-child relationships between tables. A table that extends another is known as a child class, while the extended table is the parent class. A base class is a parent class that does not extend any other table.

Show full answer Show less

This capability helps customers maintain structured data models, such as the Task table with its extended tables Incident, Problem, and Change Request, or the Configuration Item table with its various hardware and application subclasses.

Extension Models

ServiceNow offers three extension models that determine how tables and records are structured in the database:

Table per class: Creates separate database tables for each parent and child class. Fields are inherited by child classes, and records in child tables are replicated in the parent table with matching Sys IDs. This model facilitates clear separation of data while maintaining inheritance.
Table per hierarchy: Uses a single database table for the parent and all child classes. Child classes inherit fields from the parent. Each record includes a sysclassname column to identify its child class. This model eliminates record replication by storing all hierarchy records together.
Table per partition: Similar to table per hierarchy but dynamically partitions storage as table size grows. Child classes have independent fields and dictionary records, although changes in the parent class dictionary entries replicate to children. Additional storage tables are managed transparently via dictionary entries for storage details.

Practical Implications for ServiceNow Customers

Choose the extension model based on your data organization needs, storage requirements, and performance considerations.
Extending tables is only possible during table creation, so planning your data model upfront is critical.
Use the Schema Map, System Dictionary, and Tables module to view and manage relationships between parent and child tables.
Understand how fields and records are inherited or replicated to ensure data consistency and efficient querying.
For large datasets, the table per partition model helps manage storage limits seamlessly while allowing child tables to maintain distinct field definitions.

By leveraging table extensions and understanding these models, ServiceNow customers can build scalable, maintainable, and logically organized data structures that support complex business processes.

Enable one or more child tables to share fields and records with a parent table. Administrators and application developers can only extend tables during table creation.

Administrators and application developers typically extend tables to create a set of related records that share information. For example, in the base system, the Task and the Configuration Item tables have multiple extensions:

Table 1. Sample extended tables in the base system
Original table	Related tables extended from original table
Task [task]	Incident [incident] Problem [problem] Change Request [change_request]
Configuration Item [cmdb_ci]	Application [cmdb_ci_appl] Computer [cmdb_ci_computer] Database [cmdb_ci_database]

A table that extends another table is called a child class, and the table it extends is the parent class. A table can be both a parent and child class both extending and providing extensions for other tables. A parent class that is not an extension of another table is called a base class.

Administrators can use these tools to see the relationships between classes.

Schema map
System dictionary
Tables module

Extending a table:

Links the new table to the extending table.
Creates system fields in the new table.
Creates one or more database tables to store the parent and child classes. The number of tables the system creates depends upon the extension model selected during table creation.

Extension models

The ServiceNow AI Platform offers these extension models.

Table per class
Table per hierarchy
Table per partition

The extension model determines these attributes.

The number of database tables created
The derivation of fields from parent classes
The replication of records from child classes

Table per class

Tables created: Creates a separate database table for the parent class and each child class.
Fields derived from parent class: Child classes derive fields from parent classes.
Dictionary records created for parent class: A parent class has a Dictionary record for the collection and for each field that can be derived from it. For example, the Contract [ast_contract] table has 59 Dictionary records, which define the table and its fields.
Dictionary records created for child classes: Each child class only has Dictionary entries for fields unique to the class.
Records replicated: The parent class replicates each record stored in its child classes. Each child class only stores records unique to the class. Replicated records have the same Sys ID value in each table. The system replicates any change you make to a child record to the matching record in the parent table. For example, Contract [ast_contract] table replicates records from the Lease [ast_lease] and Warranty [ast_warranty] tables.

Table per hierarchy

Tables created

Creates one database table for the parent class, which stores all records for the parent and child classes. Child classes do not have separate database tables.

Fields derived from parent class

Child classes derive fields from parent classes. For example, the Incident table derives fields from the Task table.

Dictionary records created for parent class

A parent class has a Dictionary record for the collection and for each field that can be derived from it. For example, the Task table is a parent class that has 66 Dictionary records, which define the table and its fields.

The Dictionary entry for the parent class contains a sys_class_name column whose value indicates which child class each record belongs to. For example, Incident records have a sys_class_name value of incident, and change records have a sys_class_name value of change.

Dictionary records created for child classes

Each child class only has Dictionary entries for fields unique to the class. For example, the Incident table only has 22 Dictionary records, which are not already defined in the Task table.

Records replicated

Record replication is not needed, because the parent class stores all records that belong to the hierarchy. For example, the Task table contains all records from its child classes such as the Change, Incident, and Problem tables.

Table per partition

Tables created

Creates one database table for the parent class, which stores all records for the parent and child classes. Child classes do not have separate database tables. As the database table reaches a storage limit, the system dynamically adds storage tables (partitions) to store additional records.

Fields derived from parent class

Child classes do not derive fields from parent classes. Instead each child class has its own list of fields. For example, the Base Configuration Item [cmdb], Configuration Item [cmdb_ci], and Hardware [cmdb_ci_hardware] tables all have their own field definitions.

Dictionary records created for parent class

A parent class has a Dictionary record for the collection and for each field relevant to it. For example, the Base Configuration Item [cmdb] table is a parent class that has 48 Dictionary records.

The system replicates changes made to parent class Dictionary entries to child class Dictionary entries. For example, when you change the name column in the parent class Base Configuration Item [cmdb] table, the system replicates it to child class Dictionary entries such as the Configuration Item [cmdb_ci] and Hardware [cmdb_ci_hardware] tables.

The Dictionary entry for the parent class contains columns for sys_class_name and sys_class_path whose values indicate which child class each record belongs to. For example, Hardware records have a sys_class_name value of cmdb_ci_hardware, and computer records have a sys_class_name value of cmdb_ci_computer.

When the database table reaches a storage limit, the system updates the Dictionary entry for the parent class to include columns for sys_storage_alias and storage_table_name. These storage column Dictionary entries allow administrators to manage the parent class and its storage tables as a single logical unit.

Dictionary records created for child classes

Each child class has a Dictionary record for the collection and for each field relevant to it. For example, the Hardware table has 73 Dictionary records with some records duplicating columns in the parent class.

Records replicated

Record replication is not needed, because the parent class stores all records that belong to the hierarchy. For example, the Base Configuration Item [cmdb] table contains all records from its child classes such as the Application [cmdb_ci_appl], Computer [cmdb_ci_computer], and Hardware [cmdb_ci_hardware] tables.