4. 主数据属性建模:属性分类、命名规范与数据类型选择
主数据属性建模是数据模型设计的核心环节。属性是描述主数据实体特征的最小信息单元,合理的属性分类、规范的命名以及恰当的数据类型选择,直接决定了数据平台的扩展性、查询效率与集成质量。本节将系统阐述属性分类体系、命名规范原则及数据类型选型策略。
4.1 属性分类体系
根据属性在数据模型中的语义角色与用途,可将主数据属性划分为五大类别。每一类属性承担不同的数据治理职能,在建模时应分别对待。
| 属性分类 | 定义 | 典型示例 | 治理要求 |
|---|---|---|---|
| 标识属性 | 唯一确定一个实体实例的属性,不可重复、不可为空 | 设备编码、物料ID、资产编号 | 全局唯一、不可变更、由编码规则生成 |
| 描述属性 | 对实体进行自然语言说明的属性,用于理解与展示 | 设备名称、规格描述、备注 | 允许为空、支持多语言、长度可控 |
| 分类属性 | 用于对实体进行分组、归类、统计的属性 | 设备类型、资产类别、区域编码 | 引用标准代码表、层级可控、值域稳定 |
| 关系属性 | 表达实体之间关联关系的属性,通常为外键或引用 | 所属产线ID、供应商编码、父节点ID | 引用完整性、级联约束、索引优化 |
| 生命周期属性 | 记录实体从创建到退役全生命周期状态的属性 | 创建时间、状态、版本号、生效日期 | 自动填充、不可篡改、审计追溯 |
建模经验:标识属性应优先采用无意义编码(如自增ID或UUID),避免将业务含义编码作为主键,防止因业务变更导致标识失效。分类属性建议统一维护代码表,避免在应用层硬编码。
4.2 属性命名规范
统一的属性命名规范是数据平台可读性与可维护性的基础。命名规范应覆盖属性名称、数据类型、长度约束及业务含义,形成可机器解析的元数据标准。
4.2.1 命名基本原则
- 语义明确:属性名应直接反映业务含义,避免缩写歧义。例如
equipment_status优于eq_st。 - 统一风格:全平台采用小写蛇形命名法(snake_case),单词间以下划线分隔。
- 避免保留字:禁止使用数据库保留字(如
order、group、select)作为属性名。 - 长度控制:属性名不超过 30 个字符,过长时采用标准缩写表。
4.2.2 属性命名模板
推荐采用“业务域_实体_含义_后缀”的四段式命名模板,确保属性名在全局范围内唯一且可归类。
格式:{domain}_{entity}_{meaning}_{suffix}
示例:
- 设备域_设备表_额定功率_数值 → eq_equipment_rated_power_num
- 资产域_资产表_购置日期_时间 → asset_asset_purchase_date_dt
- 物料域_物料表_库存单位_代码 → mat_material_stock_unit_cd
4.2.3 常用后缀规范
| 后缀 | 含义 | 数据类型 | 示例 |
|---|---|---|---|
_id |
标识符 | BIGINT / VARCHAR | equipment_id |
_cd |
代码 | VARCHAR(20) | status_cd |
_num |
数值 | DECIMAL(18,4) | rated_power_num |
_dt |
日期时间 | TIMESTAMP | create_dt |
_txt |
文本描述 | VARCHAR(500) | description_txt |
_flag |
布尔标志 | TINYINT(1) | is_active_flag |
常见错误:属性名中混用大小写(如
equipmentName)、使用中文拼音(如 shebei_mingcheng)、后缀不统一(如 create_time 与 update_dt 混用)。这些都会导致数据字典混乱,增加集成成本。
4.3 数据类型选择策略
数据类型的选择直接影响存储效率、查询性能与数据精度。工程分析数据平台通常处理大量时序、数值与状态数据,选型时应遵循“够用、精准、一致”原则。
4.3.1 数值类型选型
| 业务场景 | 推荐类型 | 说明 |
|---|---|---|
| 整数标识、计数 | INT / BIGINT | 根据数据量选择,超过 20 亿用 BIGINT |
| 金额、精确计算 | DECIMAL(18,4) | 避免 FLOAT/DOUBLE 精度丢失 |
| 传感器测量值 | FLOAT / DOUBLE | 允许微小误差,存储效率高 |
| 百分比、比率 | DECIMAL(5,2) | 保留两位小数,范围 0.00~100.00 |
4.3.2 字符串与时间类型选型
| 业务场景 | 推荐类型 | 说明 |
|---|---|---|
| 固定长度代码 | CHAR(n) | 如国家代码、状态码 |
| 可变长度描述 | VARCHAR(n) | 根据最大长度设置 n,避免过大 |
| 大文本说明 | TEXT | 仅用于备注等长文本,避免索引 |
| 日期(无时间) | DATE | 如生效日期、采购日期 |
| 时间戳(含时区) | TIMESTAMP | 推荐 UTC 存储,应用层转换 |
4.4 属性建模流程与规范检查
以下 SVG 图展示了主数据属性建模的完整流程,从业务需求分析到属性定义完成,包含关键检查节点。
4.5 属性建模检查清单
在完成属性建模后,建议逐项核对以下检查清单,确保模型质量。
- 唯一性:每个实体是否都有明确的标识属性?标识属性是否保证全局唯一?
- 完整性:是否覆盖了所有业务所需的描述、分类、关系与生命周期属性?
- 规范性:所有属性名是否遵循命名模板?后缀是否统一?
- 类型匹配:数值属性是否选用了 DECIMAL 而非 FLOAT?时间属性是否统一为 TIMESTAMP?
- 引用完整性:关系属性是否指向已定义的主实体?外键约束是否已声明?
- 可扩展性:是否预留了扩展属性字段(如 JSON 或扩展表)以应对未来需求?
最佳实践:建议在建模工具中维护统一的属性字典,将命名规范、数据类型、默认值、约束条件以元数据形式固化。每次新增属性时,通过自动化脚本检查命名合规性与类型匹配,从源头保障数据模型质量。