导读：数据标准化的四大基础类标准（业务术语、业务规则、命名规范、代码标准）是企业数据治理的核心支柱。主要作用体现在​消除业务与技术间的语义鸿沟​（通过统一术语与命名规范），​保障数据全生命周期的质量与合规性​（依赖业务规则约束逻辑与代码标准映射权威值域），​支撑跨系统、跨组织的高效协作​（基于标准化的数据定义与交互规则），以及赋能数据驱动决策​（确保数据的准确性、一致性与可解释性）。这些标准共同构建了数据资产的“通用语言”体系，是数字化转型的基石，能够降低集成成本、规避合规风险，并为人工智能、大数据分析等场景提供可信赖的数据底座。

目录

1. 业务术语（Business Glossary）​

​2. 业务规则（Business Rules）​

​3. 命名规范（Naming Convention）​

3.1 命名规范要求

3.2 缩写原则

 3.3 模型元素组词结构

3.4 常见命名规范

​4. 代码标准（Code Standards）​

 4.1 国际代码标准表

4.2 国内代码标准表

4.3 行业代码标准表

---

概述： 数据标准化的四大基础类标准（业务术语、业务规则、命名规范、代码标准）相互关系。

---

1. 业务术语（Business Glossary）​

定义：业务术语是对企业核心业务概念的统一、标准化的定义，确保不同部门对同一术语的理解一致。
作用：消除歧义，促进跨部门协作，支撑数据治理和数据质量。
实例：

• ​术语名称：客户

  • ​定义：与企业签订正式合同并产生交易记录的自然人或法人。
  • ​范围：不包括潜在客户、已注销客户。
  • ​示例：某银行的“客户”需满足“开户且最近6个月有交易记录”。

• ​术语名称：订单金额

  • ​定义：订单的实际支付金额，含税费、折扣，不含运费。
  • ​规则：需与财务系统中的“实收金额”一致。

术语表实例：

字段名称	示例值	说明
​业务术语ID	T-001	唯一标识符，用于系统引用（技术用户）
​业务术语名称	客户	标准名称（业务用户）
​定义	与企业签订正式合同并产生交易记录的自然人或法人，不包括潜在客户和已注销客户。	清晰描述术语范围（业务用户）
​缩写/简称	CST	技术系统中使用的简称（技术用户）
​同义词	顾客、消费者	其他部门可能使用的名称（业务用户）
​数据源头	CRM系统、订单管理系统	数据来源系统（数据管理专员）
​维护人员	数据治理团队（张三）	责任人（数据管理专员）
​更新日期	2023-10-01	最后修订时间（数据管理专员）
​分类	客户管理	所属业务域（技术用户）
​关联关系	关联术语：客户ID（T-002）、客户状态（T-003） 关联数据实体：客户表（dim_customer）	与其他术语或数据实体的映射（技术用户）
​业务规则	客户状态为“活跃”时，最近6个月内必须有交易记录。	约束条件（业务用户）
​技术映射	数据库字段：customer_status API字段：/api/customer/{id}	技术实现细节（技术用户）

---

业务术语满足不同角色的需求

1. ​业务用户：

   • 通过定义、同义词、业务规则明确业务含义，避免歧义。
   • 例如：区分“客户”与“潜在客户”。

2. ​数据管理专员：

   • 通过数据源头、维护人员、更新日期追踪数据血缘和治理责任。
   • 例如：客户数据来自CRM系统，由张三负责维护。

3. ​技术用户：

   • 通过技术映射、关联关系、缩写实现数据建模和系统开发。
   • 例如：客户状态映射到数据库字段customer_status，关联客户表主键。

---

​2. 业务规则（Business Rules）​

定义：对数据生成、处理、使用的逻辑约束和规范，确保数据的完整性、一致性和合规性。
作用：保障数据的业务有效性，避免脏数据。

---

业务规则的三大分类（全局规则、交互规则、内禀规则）的定义及实例

​分类	​定义	​特点	​实例	​技术实现方式
​全局规则	跨系统、全企业通用的基础规则，通常与数据标准或合规性相关。	- 普适性 - 强制性 - 静态约束	1. 手机号格式必须为11位数字且以1开头。 2. 国家编码必须使用ISO 3166标准。	- 中央规则引擎（如Drools） - ETL工具校验 - 数据治理平台统一配置
​交互规则	多个系统/实体交互时的逻辑约束，确保数据流转和业务流程的一致性。	- 关联性 - 动态性 - 依赖外部状态	1. 订单创建时库存必须充足。 2. 用户注销需检查关联订单状态。	- API调用校验（如RESTful接口） - 分布式事务锁（如Saga模式） - 消息中间件
​内禀规则	单个实体内部字段的独立约束，仅依赖自身属性。	- 独立性 - 静态性 - 字段级校验	1. 性别字段仅允许0/1/2。 2. 商品价格必须大于0且保留两位小数。	- 数据库约束（NOT NULL、CHECK） - 代码层校验（如Java Bean Validation）

 

• ​全局规则是顶层约束，为交互和内禀规则提供基础；【企业级“宪法”，不可绕过。】
• ​交互规则依赖内禀规则（如订单总金额需先满足内禀计算规则）；【系统间协作的“合同”，需动态协调。】
• ​内禀规则是数据质量的最小单元。【数据实体的“基因”，确保单体健康。】

---

​3. 命名规范（Naming Convention）​

定义：对数据库表、字段、文件、接口等对象的命名规则，提升数据资产的可读性和管理效率。
作用：降低沟通成本，快速定位数据资产。
实例：

• ​数据库表命名：业务域_实体_用途

  • ​示例：fin_payment_record（财务域-支付记录表）
  • ​规则：全小写，单词间用下划线分隔。

• ​字段命名：属性_修饰词

  • ​示例：user_name（用户名）、order_create_time（订单创建时间）

• ​文件命名：业务主题_日期_版本

  • ​示例：sales_report_202310_v1.xlsx

---

3.1 命名规范要求

​分类	​规范描述	​实例	​反例/注意事项
​命名规范要求
1. ​清晰性	名称需明确反映业务含义，避免歧义。	customer_id（客户ID） order_total_amount（订单总金额）	cust_id（缩写不明确） total（含义模糊）
2. ​一致性	同类对象命名格式统一（如全用单数或全用复数）。	表名统一复数：customers, orders 布尔字段统一以is_开头：is_active	混合格式：customer（单数）和orders（复数）
3. ​简洁性	名称不宜过长，但需保留核心语义。	addr（address缩写） prod_code（product_code缩写）	customer_identification_number（过长，可简化为customer_id）
4. ​可读性	使用蛇形命名法（snake_case）或驼峰法（camelCase），避免特殊符号。	user_role（蛇形） userRole（驼峰）	UserRole（帕斯卡，可能混淆） user-role（连字符不建议）

---

3.2 缩写原则

​缩写原则
1. ​常见缩写	使用广泛接受的缩写（如ID代替Identifier）。	id（标识符） qty（数量） amt（金额）	cust（可能指customer或customization，需避免歧义）
2. ​领域一致性	同一领域内缩写规则需统一（如金融领域amt表示金额）。	金融表字段：txn_amt（交易金额） acct_no（账户编号）	混合使用：amount和amt出现在同一模型中
3. ​避免过度缩写	缩写需确保团队共识，避免生僻缩写。	addr（address） desc（description）	cust_addr（客户地址可接受） usr_lctn（user_location，生僻缩写不推荐）

---

 3.3 模型元素组词结构

模型元素组词结构
1. ​表名	实体名称（复数）+业务域（可选）。	users（用户表） sales_orders（销售订单表）	user（单数表名） order_sales（顺序不符合习惯）
2. ​字段名	属性名+类型后缀（可选）。	created_at（创建时间） price_usd（美元价格）	create_time（冗余） usd_price（顺序不符合习惯）
3. ​关联字段	外键字段格式：关联表名（单数）_id。	customer_id（关联customers表） product_id（关联products表）	cust_id（缩写不统一） id_product（顺序错误）
4. ​索引/约束	类型+表名+字段名。	idx_users_email（用户邮箱索引） uk_products_code（产品编码唯一约束）	index1（无意义名称） unique_code（缺少表名信息）

---

3.4 常见命名规范

常见命名规范
1. ​主键	统一命名为id。	id（表users的主键）	user_id（主键不建议带表名）
2. ​日期字段	时间类型字段以_at或_date结尾。	created_at（创建时间） expiry_date（到期日期）	create_time（不统一） expire（缺少类型标识）
3. ​布尔字段	以is_、has_或can_开头。	is_active（是否激活） has_license（是否有许可证）	active（缺少布尔标识） license_status（建议用has_license）
4. ​枚举字段	以_type或_status结尾。	order_type（订单类型） payment_status（支付状态）	type（过于笼统） status（需结合业务域，如user_status）

---

 总结：

1. ​命名规范要求：确保清晰、简洁、一致，优先使用蛇形命名法。
2. ​缩写原则：遵循领域共识，避免歧义缩写。
3. ​组词结构：表名复数，字段名“属性+修饰”，外键格式统一。
4. ​常见规范：主键用id，布尔字段加前缀，日期字段加后缀。

---

​4. 代码标准（Code Standards）​

定义：对编码规则、代码值及其含义的标准化定义，确保代码在系统中的唯一性和可解释性。
作用：支持数据整合与分析，避免编码冲突。
实例：

• ​代码类型：状态码

  • ​规则：用两位数字表示订单状态。
  • ​示例：
    • 01：已下单
    • 02：已支付
    • 03：已发货

• ​代码类型：国家/地区编码

  • ​标准：采用ISO 3166-1国际标准。
  • ​示例：CN（中国）、US（美国）

• ​代码类型：性别编码

  • ​规则：统一用数字表示，避免“男/女”、“M/F”混用。
  • ​示例：1（男）、2（女）、0（未知）

---

 4.1 国际代码标准表

​分类	​标准名称/编号	​定义与范围	​示例	​典型应用场景
​国际通用	ISO 3166-1（国家/地区代码）	定义全球国家/地区的2位字母码、3位字母码及数字码。	CN（中国）、US（美国）	跨国数据交换、地理位置标识
	ISO 4217（货币代码）	标准货币的3字母代码（如美元、欧元）。	USD（美元）、EUR（欧元）	跨境支付、财务系统结算
	RFC 3629（UTF-8编码）	统一字符编码标准，支持多语言文本。	U+4E2D（中文“中”）	全球化系统开发、多语言数据存储
​国际行业	GS1（商品条码标准）	全球商品标识（GTIN、EAN/UPC条形码）。	6921234567890（中国产商品条码）	零售库存管理、物流追溯
	SWIFT/BIC Code	银行国际代码，标识金融机构。	ICBKCNBJXXX（中国工商银行）	国际汇款、跨境资金清算
	IATA机场代码	全球机场三字母标识码。	PEK（北京首都机场）、JFK（纽约）	航空订票、物流跟踪

---

4.2 国内代码标准表

分类	​标准名称/编号	​定义与范围	​示例	​典型应用场景
​国家统一	GB/T 2260（行政区划代码）	中国省、市、县三级行政区划6位数字代码。	110000（北京市）	户籍管理、统计数据上报
	GB/T 4754（国民经济行业分类）	中国国民经济行业分类与代码（门类、大类、中类）。	A01（农业）	经济统计、行业分析
	统一社会信用代码	中国法人及其他组织的18位唯一标识码。	91350100MA345R****（福建某企业）	企业注册、税务登记
​行业标准	CNAPS（支付系统行号）	中国现代化支付系统的12位银行行号。	102100000013（中国银行总行）	银行间清算、跨行转账
	公民身份证号码	18位公民唯一标识（地区+生日+顺序码+校验码）。	110101199001011234	身份核验、政务服务
	医保药品分类与代码	国家医保局药品分类标准（西药、中成药等）。	X0001（阿司匹林）	医保报销、药品采购

---

4.3 行业代码标准表

分类	​标准名称/编号	​定义与范围	​示例	​典型应用场景
​金融	ISIN（证券国际代码）	国际证券识别码（12位字母数字组合）。	US0378331005（苹果公司股票）	跨境证券交易、资产管理
	CFETS外汇交易代码	中国外汇交易中心货币对交易代码。	USDCNY（美元对人民币）	外汇交易、汇率报价
​医疗	ICD-10（疾病分类代码）	WHO国际疾病与健康问题分类（10版）。	J18.9（未特指肺炎）	医疗诊断、保险理赔
	医保药品目录编码	国家医保药品目录分类与唯一代码。	YB0000001（某抗癌药）	医保支付、医院药房管理
​交通运输	HJ 1234（车牌号编码规则）	中国机动车号牌编码规则（省份简称+字母数字组合）。	京A12345（北京车牌）	车辆登记、交通执法
​电子商务	GTIN（全球贸易项目代码）	商品全球唯一标识（与GS1国际标准对齐）。	6931234500007（某商品条码）	电商平台商品管理、跨境物流