2. 主数据模型基础：主数据定义、模型构成要素与元数据管理
2.1 主数据定义与工程分析语境
在工程分析数据平台中，主数据（Master Data）是指描述企业核心业务实体（如产品、设备、项目、组织、人员）的基准数据，是跨系统、跨流程共享的“黄金记录”。与交易数据（如订单、工单、测量值）不同，主数据具有高复用性、低变更频率、强引用性的特征。
| 维度 | 交易数据 | 主数据 |
|---|---|---|
| 变更频率 | 高频（秒/分钟级） | 低频（天/周/月级） |
| 生命周期 | 短（完成后归档） | 长（持续维护） |
| 共享范围 | 局部（单个流程） | 全局（跨部门/系统） |
| 工程分析示例 | 某次仿真运行的温度值 | 材料牌号、标准件编号、设备型号 |
关键认知：主数据模型是工程分析数据平台的“骨架”。版本迁移的核心不是搬运数据，而是确保骨架结构在迁移前后语义一致、关系完整。
2.2 模型构成要素：实体、属性、关系
主数据模型由三个基本要素构成，三者共同定义了数据的结构、语义与约束。
2.2.1 实体（Entity）
实体是现实世界中可独立识别的对象或概念，在模型中对应一张表或一个对象类型。工程分析中常见实体包括：产品、设备、项目、组织、人员、文档、物料。
2.2.2 属性（Attribute）
属性描述实体的特征或状态。每个属性包含名称、数据类型、长度、约束（主键、非空、唯一、默认值）等元信息。
| 实体 | 属性示例 | 数据类型 | 约束 |
|---|---|---|---|
| 产品 | 产品编号 | VARCHAR(32) | 主键、非空 |
| 产品 | 产品名称 | VARCHAR(128) | 非空 |
| 设备 | 设备序列号 | VARCHAR(64) | 主键、非空 |
| 设备 | 安装日期 | DATE | 可空 |
2.2.3 关系（Relationship）
关系定义实体之间的连接方式，常见类型包括：
- 1:1（一对一）：一个产品对应一个当前版本。
- 1:N（一对多）：一个项目包含多个仿真任务。
- M:N（多对多）：一个设备可用于多个项目，一个项目使用多台设备。
版本迁移关注点：关系约束（如外键、级联删除）在迁移时必须保持完整，否则会导致数据引用断裂或孤儿记录。
2.3 元数据管理
元数据（Metadata）是“关于数据的数据”，它描述主数据模型的结构、语义、来源、质量与血缘。元数据管理是数据治理的基石，直接影响版本迁移的可追溯性与一致性。
2.3.1 元数据分类
| 类型 | 描述 | 工程分析示例 |
|---|---|---|
| 技术元数据 | 数据库表结构、字段类型、索引、分区 | 表名：t_product，字段：prod_id VARCHAR(32) |
| 业务元数据 | 业务定义、计算规则、数据质量规则 | “产品编号”编码规则：P-YYYYMM-XXXX |
| 管理元数据 | 数据所有者、创建时间、版本号、审批状态 | 模型版本 v2.1，审批人：张三，生效日期：2025-01-15 |
2.3.2 元数据管理核心活动
- 采集与注册：从源系统（如 PLM、ERP、仿真平台）自动或手动采集元数据，注册到元数据中心。
- 版本化：每次主数据模型变更时，元数据同步生成新版本，记录变更差异。
- 血缘分析：追踪数据从源到目标的流转路径，识别模型变更影响范围。
- 质量监控：基于元数据规则（如非空、唯一、引用完整性）定期校验数据质量。
版本迁移风险提示：元数据缺失或不一致是版本迁移失败的首要原因。迁移前必须完成元数据基线审计，确保源端与目标端的元数据定义完全对齐。
2.4 主数据模型与元数据的关系
主数据模型与元数据是“数据”与“数据的数据”的关系。主数据模型定义业务数据的结构，元数据则描述该结构本身。在版本迁移场景中，两者必须同步演进：
- 模型变更 → 元数据更新：新增实体、修改属性、调整关系后，元数据必须立即反映最新定义。
- 元数据驱动迁移：迁移工具读取元数据中的表结构、约束、索引信息，自动生成 DDL 与 ETL 脚本。
- 元数据校验：迁移完成后，通过元数据对比源端与目标端的模型定义，确保完全一致。
最佳实践：在工程分析数据平台中，建议将主数据模型与元数据存储在同一个版本控制仓库（如 Git）中，每次模型变更提交时自动触发元数据版本标签，实现“模型即代码、元数据即文档”。