资讯

历史

科技

环境与自然

成长

游戏

财经

文学与艺术

美食

健康

家居

文化

情感

汽车

三农

军事

旅行

运动

教育

生活

星座命理

数据标准化框架体系-基础类数据标准

创作时间:

作者:

@小白创作中心

数据标准化框架体系-基础类数据标准

引用

CSDN

https://blog.csdn.net/weixin_43800786/article/details/146762044

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

1. 业务术语（Business Glossary）

定义：业务术语是对企业核心业务概念的统一、标准化的定义，确保不同部门对同一术语的理解一致。

作用：消除歧义，促进跨部门协作，支撑数据治理和数据质量。

实例：

术语名称：客户
定义：与企业签订正式合同并产生交易记录的自然人或法人。
范围：不包括潜在客户、已注销客户。
示例：某银行的“客户”需满足“开户且最近6个月有交易记录”。
术语名称：订单金额
定义：订单的实际支付金额，含税费、折扣，不含运费。
规则：需与财务系统中的“实收金额”一致。

术语表实例：

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

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

业务用户：

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

数据管理专员：

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

技术用户：

通过技术映射、关联关系、缩写实现数据建模和系统开发。
例如：客户状态映射到数据库字段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）

总结：

命名规范要求：确保清晰、简洁、一致，优先使用蛇形命名法。
缩写原则：遵循领域共识，避免歧义缩写。
组词结构：表名复数，字段名“属性+修饰”，外键格式统一。
常见规范：主键用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（某商品条码）	电商平台商品管理、跨境物流