3. 数据模型基础理论

在工程分析数据平台中，数据模型是连接业务需求与技术实现的桥梁。本章系统梳理五种核心数据模型——概念模型、逻辑模型、物理模型、ER模型与维度模型——并重点分析它们在工程领域的适用场景与选择策略。

3.1 数据模型的三层抽象体系

ANSI/SPARC 架构将数据模型划分为三个抽象层次，从业务视角逐步过渡到技术实现视角。工程领域的数据建模通常遵循这一分层体系，以确保模型既贴近业务语义，又具备高效的物理存储性能。

3.2 概念模型：工程语义的顶层抽象

概念模型使用业务语言描述工程领域中的核心实体及其关系，不涉及技术细节。它是数据治理的起点，也是跨团队沟通的通用语言。

• 实体定义： 如“设备资产”、“工艺参数”、“质量检测批次”、“维修工单”。
• 关系描述： 如“设备资产 产生 工艺参数”、“质量检测批次 关联 设备资产”。
• 业务规则： 如“一台设备在同一时刻只能执行一个工艺任务”。

概念模型通常采用 实体-关系图（ERD） 的简化形式，但只保留实体框与关系连线，不包含属性细节。

3.3 逻辑模型：规范化与数据治理的核心战场

逻辑模型在概念模型的基础上，细化每个实体的属性、主键、外键，并应用规范化理论（通常到第三范式）消除数据冗余。它是数据治理规则落地的关键层次。

• 属性定义： 每个属性需明确数据类型、长度、是否为空、默认值。
• 主键策略： 工程实体通常使用复合主键，如“设备ID + 时间戳”标识一条工艺参数记录。
• 外键约束： 建立实体间的引用关系，如“质量检测批次”引用“设备资产”的设备ID。
• 规范化检查： 确保每个非主键属性完全依赖于主键，消除传递依赖。

-- 逻辑模型示例：设备资产表（第三范式）
CREATE TABLE dim_device (
    device_id       VARCHAR(32)   NOT NULL,
    device_name     VARCHAR(128)  NOT NULL,
    device_type     VARCHAR(64),
    plant_id        VARCHAR(16)   NOT NULL,
    install_date    DATE,
    status          VARCHAR(16),
    PRIMARY KEY (device_id),
    FOREIGN KEY (plant_id) REFERENCES dim_plant(plant_id)
);

-- 逻辑模型示例：工艺参数事实表（引用设备与时间）
CREATE TABLE fact_process_param (
    device_id       VARCHAR(32)   NOT NULL,
    param_time      TIMESTAMP     NOT NULL,
    param_code      VARCHAR(32)   NOT NULL,
    param_value     DECIMAL(18,4),
    unit            VARCHAR(16),
    quality_flag    VARCHAR(8),
    PRIMARY KEY (device_id, param_time, param_code),
    FOREIGN KEY (device_id) REFERENCES dim_device(device_id)
);

3.4 物理模型：面向性能与存储的技术实现

物理模型将逻辑模型转换为具体的数据库表结构、索引、分区、存储引擎等物理实现方案。工程分析平台通常面临海量时序数据，物理模型的设计直接影响查询响应时间与存储成本。

-- 物理模型示例：基于时间分区的工艺参数表（PostgreSQL）
CREATE TABLE fact_process_param (
    device_id       VARCHAR(32)   NOT NULL,
    param_time      TIMESTAMP     NOT NULL,
    param_code      VARCHAR(32)   NOT NULL,
    param_value     DECIMAL(18,4),
    unit            VARCHAR(16),
    quality_flag    VARCHAR(8)
) PARTITION BY RANGE (param_time);

-- 创建月度分区
CREATE TABLE fact_process_param_202501 PARTITION OF fact_process_param
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

CREATE TABLE fact_process_param_202502 PARTITION OF fact_process_param
    FOR VALUES FROM ('2025-02-01') TO ('2025-03-01');

-- 创建复合索引
CREATE INDEX idx_device_time ON fact_process_param (device_id, param_time);

3.5 ER模型与维度模型：两种核心建模范式

在工程分析平台中，ER模型与维度模型是两种最常用的建模范式，分别适用于不同的业务场景。

3.5.1 ER模型：面向事务处理的规范化建模

ER模型以实体-关系为核心，强调数据完整性、一致性与最小冗余。它适用于OLTP（在线事务处理）场景，如工单管理、设备台账维护、物料出入库等。

• 优势： 数据冗余低，更新一致性好，适合频繁的增删改操作。
• 劣势： 多表关联查询复杂，在大数据量下分析性能较差。
• 工程适用场景： 设备资产主数据管理、维修工单系统、备件库存管理。

3.5.2 维度模型：面向分析查询的星型/雪花型建模

维度模型以“事实表 + 维度表”为核心，通过星型或雪花型结构优化分析查询性能。它适用于OLAP（在线分析处理）场景，如工艺参数趋势分析、设备综合效率（OEE）计算、质量根因分析等。

• 事实表： 存储可量化的度量值，如温度、压力、产量、缺陷数。通常包含多个外键指向维度表。
• 维度表： 存储描述性属性，如设备维度、时间维度、产品维度、工艺维度。
• 优势： 查询性能高，易于理解，适合BI工具直接使用。
• 劣势： 数据冗余较大，更新维护成本较高。
• 工程适用场景： 产线KPI看板、质量分析报表、能耗分析平台。

3.6 工程领域模型选择决策框架

以下SVG图展示了在工程分析平台中，根据业务场景选择数据模型的决策流程。

3.7 工程领域模型设计最佳实践

基于工程分析数据平台的实际项目经验，总结以下模型设计原则：

1. 业务驱动优先： 概念模型必须由业务专家主导，确保实体和关系准确反映工程语义。
2. 规范化与反规范化的平衡： 逻辑模型保持第三范式，物理模型根据查询模式适度反规范化（如预聚合、冗余维度属性）。
3. 时间维度无处不在： 工程数据天然具有时序特征，所有事实表都应包含时间戳，并考虑时间分区策略。
4. 主数据标准化先行： 设备、产品、工艺等核心维度应建立统一的主数据管理规范，确保跨系统一致性。
5. 模型版本管理： 工程业务规则会随工艺改进而变化，数据模型应支持版本迭代，并保留变更历史。