2. 主数据模型设计原则详解

主数据模型是工程分析数据平台的“骨架”，它定义了核心业务实体（如设备、测点、工况、分析任务）的结构、属性和关系。一个设计不良的模型会导致数据冗余、接口混乱、看板指标不一致。本章详细阐述五大核心设计原则：标准化、唯一性、一致性、稳定性与可扩展性。

2.1 标准化 (Standardization)

标准化要求主数据模型遵循统一的数据类型、命名规范、编码规则和度量单位。这是实现跨系统、跨部门数据互通的先决条件。

• 命名规范： 采用 PascalCase 或 snake_case 统一命名表名、字段名。例如：EquipmentMaster 而非 equip_mst 或 设备主表。
• 编码规则： 为每个主数据实体（如设备、测点）定义全局唯一的编码体系。例如：设备编码 = “EQ-” + 工厂代码 + “-” + 流水号。
• 数据类型与单位： 温度统一使用 DECIMAL(10,2)，单位固定为“摄氏度(℃)”；压力统一使用 DECIMAL(12,4)，单位固定为“兆帕(MPa)”。

2.2 唯一性 (Uniqueness)

唯一性原则确保每个主数据实体在平台内只存在一个权威的、无歧义的表示。这是消除数据冗余和更新异常的关键。

• 主键约束： 每个主表必须定义业务主键（Natural Key）或代理主键（Surrogate Key）。例如，equipment_id 作为设备表的唯一标识。
• 业务唯一索引： 对业务上要求唯一的字段组合（如“工厂代码 + 设备编码”）建立唯一索引，防止重复录入。
• 黄金记录： 当存在多个数据源时，通过数据治理规则确定唯一的“黄金记录”（Golden Record），其他源作为参考或历史。

-- 示例：在设备主表中创建唯一索引
CREATE UNIQUE INDEX idx_equipment_plant_code
ON equipment_master (plant_code, equipment_code);

2.3 一致性 (Consistency)

一致性原则要求数据在模型内部、模型之间以及不同时间点上保持逻辑上的和谐与统一。它直接决定了看板指标的可信度。

• 引用完整性： 外键约束必须启用。例如，“测点表”中的 equipment_id 必须在“设备表”中存在。不允许出现孤立的测点记录。
• 值域一致性： 状态字段（如设备运行状态：运行、停机、检修）必须使用统一的枚举值，禁止在A系统用“1/2/3”，在B系统用“Run/Stop/Maintain”。
• 计算逻辑一致性： 看板中的“设备可用率”指标，其计算公式（可用时间 / 日历时间）必须在模型层定义，并确保所有下游消费方使用同一逻辑。

2.4 稳定性 (Stability)

稳定性原则要求主数据模型的核心结构在较长周期内保持相对不变。频繁的模型变更会导致下游接口、ETL任务和看板报表的连锁故障。

• 核心属性冻结： 标识字段（ID、Code）、关键业务字段（如设备类型、所属工厂）一旦发布，禁止修改或删除，只能标记为“废弃”。
• 向下兼容： 当必须扩展模型时，优先采用“新增字段”或“新增表”的方式，确保旧版接口仍能正常工作。
• 版本管理： 对模型定义进行版本控制（如 V1.0, V1.1），并记录每次变更的兼容性说明。

2.5 可扩展性 (Scalability)

可扩展性要求模型能够在不破坏现有结构的前提下，适应新的业务需求、新的数据源和新的分析场景。

• 抽象化设计： 使用“类型-实例”模式。例如，不直接创建“温度测点表”和“压力测点表”，而是创建“测点主表” + “测点类型字典”。
• 预留扩展字段： 在核心表中预留少量通用字段（如 attr_1, attr_2）或使用 JSON 字段存储非结构化扩展信息。
• 微服务化模型： 将紧密关联的实体聚合为领域模型（如设备域、测点域、分析域），域间通过标准接口交互，域内可独立演进。

2.6 原则冲突与权衡

在实际工程中，五大原则之间可能存在冲突。例如，过度追求稳定性可能会牺牲可扩展性；过度强调唯一性可能导致模型过于刚性。数据架构师需要根据业务场景进行权衡。