Schema Design Security and Approval Workflow Overview - Data Management

The Schema Design module in Data Management Service (DMS) governs schema changes from design to publication. Use it to define validation rules, set risk thresholds, and configure approval processes so every schema change meets your team's standards before reaching production.

How it works

A schema design ticket moves through two stages:

Save changes — DMS validates table headers, fields, and indexes against your design rules before saving.
Apply changes — DMS calculates a risk level based on your risk identification rules, then routes the ticket through the matching approval process.

When a ticket spans multiple instances — for example, designing in a test environment and publishing to production — the basic configuration items, design rules, and risk identification rules apply to the base database (test environment). The approval process, however, uses the security rules configured for the production environment.

Key concepts

R&D process

The R&D process defines the full lifecycle of a schema design ticket and is the most important configuration item in the Schema Design module.

A process contains two node types:

Node type	Description
Design	Determines the environment where the schema change is designed. Generated by default and cannot be removed.
Publish	Publishes the schema change after design. You can add multiple Publish nodes.

Each node has the following parameters:

Parameter	Description
Node name	A name up to 10 characters.
Database environment	The environment where the node runs.
Execution strategy	Immediately: runs as soon as the node is approved. Periodically: runs at a scheduled time. If the node is approved before the scheduled time, it runs as scheduled. If approved after, the node is interrupted and not run.
Can go back	Whether a Publish node can roll back to the Design node.
Can skip	Whether the current node can be skipped.
Anchor	Marks the node as a stop point. After an anchor node is published, subsequent nodes are blocked and the ticket enters the Published state.
Actions	Operations available on a Publish node, including removing the node.

To automatically advance a ticket to the Ended state after publishing, set the last node in the R&D process as the anchor, then enable Advance ticket to the Ended state when published.

Checkpoints

DMS evaluates schema changes at two stages, each with a set of checkpoints:

Saving changes — validates structure before saving:

Save Changes and Validate Header
Save Changes and Validate Field
Save Changes and Validate Index

Applying changes — identifies risk and assigns approval:

Table Creation Risk Control
Field Change Risk Control
Index Change Risk Control
SQL Execution Risk Control
Approval Rule Validation

The first four checkpoints calculate risk levels for Data Definition Language (DDL) changes. The Approval Rule Validation checkpoint routes tickets to the appropriate approval process based on those risk levels.

If Approval Rule Validation is not configured, DMS falls back to the Default approval template for schema design set in the basic configuration items.

Factors and actions

Security rules are written as Domain-Specific Language (DSL) statements using factors and actions.

Factors are built-in variables that provide context about the change — for example, the table type, table size, or environment. A factor name uses the prefix @fac. followed by the display name.

The following factors are available for Schema Design checkpoints:

Factor	Description
`@fac.table_kind`	Type of table being changed. Values: `new` (newly created), `old` (existing).
`@fac.column_kind`	Type of field being changed. Values: `new` (newly created), `old` (existing).
`@fac.xxxx_old`	Current value of an existing field or index, used for comparison.
`@fac.column_is_primary`	Whether the field is a primary key. Values: `true`, `false`.
`@fac.column_type_support_default`	Whether the field's data type supports a default value. Values: `true` (for example, `CHAR`), `false` (for example, `TEXT`).
`@fac.index_kind`	Type of index being changed. Values: `new`, `old`.
`@fac.index_column_count`	Number of fields in the index.
`@fac.change_type`	Type of DDL operation. Values: `new` (add), `modify`, `delete`.
`@fac.altered_table_size`	Size of the table being changed, in MB.
`@fac.online_execute`	Whether the change can run in an online environment. Values: `true`, `false`.
`@fac.change_risk_level`	Calculated risk level. Values: `high`, `middle`, `low`.
`@fac.env_type`	Environment type display name, such as `DEV` or `PRODUCT`. See Change the environment type of an instance.

Actions are the operations DMS performs when rule conditions are met. An action name uses the prefix @act. followed by the display name.

The following actions are available for Schema Design checkpoints:

Action	Description
`@act.block_submit`	Blocks the schema change from being submitted and displays an error message. Used in the save changes process. Format: `@act.block_submit 'Reason'`.
`@act.show_warning`	Displays a warning without blocking submission. Used in the save changes process. Format: `@act.show_warning 'Message'`.
`@act.mark_middle_risk`	Marks the schema change as medium risk. Used in risk identification. Format: `@act.mark_middle_risk 'Reason'`.
`@act.mark_high_risk`	Marks the schema change as high risk. Used in risk identification. Format: `@act.mark_high_risk 'Reason'`.
`@act.forbid_submit_publish`	Rejects the ticket. Used in approval rule validation. Format: `@act.forbid_submit_publish 'Reason'`.
`@act.do_not_approve`	Specifies the ID of an approval template. For more information, see Configure approval processes.
`@act.choose_approve_template`	—
`@act.choose_approve_template_with_reason`	—

Security rule templates

DMS includes predefined security rule templates for each checkpoint. Enable them directly or customize them to fit your requirements.

Templates are organized by what they govern:

Naming and structure rules (applied at header and field validation checkpoints)

Table name cannot contain specified keywords
Table name length is limited
New tables require a description
New tables require lowercase names
New tables require a primary key
New tables require a unique key
New tables require specified fields
Field name cannot contain specified keywords
New fields require a description
Field names require uppercase or lowercase letters

Field constraints (applied at field validation checkpoints)

Non-null fields added to an existing table require a default value
Existing fields changed from nullable to non-null require a default value
Primary key fields must be of the INTEGER type
All fields in a new table must be assigned values
CHAR field length is limited
VARCHAR field length is limited

Index rules (applied at index validation checkpoints)

Index name cannot contain specified keywords
Index names require uppercase or lowercase letters
New indexes must be unique indexes
New indexes must be normal indexes
New indexes must be of the FULLTEXT type
New indexes must be of the SPATIAL type
Number of primary key fields is limited
Number of index fields is limited
Index count per table is limited; alerts are sent when the threshold is reached

Risk identification rules (applied at risk control checkpoints)

Number of table shards in a logical table is limited
Number of primary keys per table is limited
Number of indexes per table is limited
Specified fields cannot be deleted
Field data type of new fields is restricted
Fields cannot be renamed to specified names
Fields cannot be changed to specified data types
Primary keys cannot be deleted
Indexes cannot be deleted
Primary keys cannot be changed to regular indexes
Primary key columns cannot contain specified fields
Normal indexes cannot be changed
Type of new indexes is restricted
Instances cannot be core instances
Tables cannot use specified storage engines
Tables are locked when their size exceeds the specified limit

Approval routing rules (applied at the Approval Rule Validation checkpoint)

DDL changes to database schemas are blocked
DDL changes to production database schemas are blocked
DDL changes in test environments do not require approval
Different approval processes apply for different risk levels in production

Other configuration items

Configuration item	Description
Field type configuration	Supported data types for newly added fields.
Index type configuration	Supported data types for newly added indexes.
Table creation template	A template that preloads configured fields and indexes when creating a table. Optional — use it only if your team needs a standard table structure.
Table character sets	Character sets available when creating a table, such as `utf8` and `utf8mb4`.
Prohibit modifying the original field data type	Prevents changing data types of existing fields when modifying a table.
Prohibit deleting original fields	Prevents deleting existing fields when modifying a table. Deleting fields carries high risk — enable this setting unless you have a specific reason not to.
Prohibit renaming original fields	Prevents renaming existing fields when modifying a table. Renaming fields carries high risk — enable this setting unless you have a specific reason not to.
Enable non-peer publishing	By default, changes to a table can only be published to a table with the same name in another database. Enable this option to publish changes to any table.

Warning

Non-peer publishing carries high risk. Enable it only for special requirements.

Change the default approval template

Log on to the DMS console V5.0.
Move the pointer over the icon in the upper-left corner and choose All Features > Security and Specifications (DBS) > Security Rules.
In normal mode, choose Security and Specifications (DBS) > Security Rules in the top navigation bar.
Move the pointer over the icon in the upper-left corner and choose All Features > Security and disaster recovery (DBS) > Security Rules.

Note
If you use the DMS console in normal mode, choose Security and disaster recovery (DBS) > Security Rules in the top navigation bar.
Move the pointer over the icon in the upper-left corner and choose All Features > Security and disaster recovery (DBS) > Security Rules.

Note
If you use the DMS console in normal mode, choose Security and disaster recovery (DBS) > Security Rules in the top navigation bar.
Find the security rule set to modify and click Edit in the Actions column.
In the left-side navigation pane of the Details page, click the Schema Design tab.
Click Basic Configuration Items.
Find Default approval template for schema design and click Edit in the Actions column.
In the Change Configuration Item dialog box, click Switch Approval Template.
Find the template to apply and click Select in the Actions column.
To skip approval for tickets, click Reset to Free of Approval.
Click Submit.

Create a security rule

Log on to the DMS console V5.0.
Move the pointer over the icon in the upper-left corner and choose All Features > Security and Specifications (DBS) > Security Rules.
In normal mode, choose Security and Specifications (DBS) > Security Rules in the top navigation bar.
Find the security rule set to modify and click Edit in the Actions column.
In the left-side navigation pane of the Details page, click the Schema Design tab.
Click Create Rule next to Actions.

In the Create Rule - Schema Design dialog box, set the following parameters:

Parameter	Required	Description
Checkpoints	Yes	The checkpoint for this rule. See Checkpoints.
Template database	No	A built-in template to base the rule on. After selecting a checkpoint, click Load from Template Database to browse available templates. See Security rule templates.
Rule name	Yes	A custom name for the rule. Auto-filled when loading from a template.
Rule DSL	Yes	The DSL statement that defines the rule logic. Auto-filled when loading from a template.

Click Submit.
Find the newly created rule (it is in the Disabled state by default) and click Enable in the Actions column.
In the confirmation message, click OK.