2. 数据模型设计基础理论
数据模型是工程分析数据平台的骨架。一个健壮的数据模型，必须准确回答三个问题：描述什么对象（实体）、对象有哪些特征（属性）、对象之间如何关联（关系）。在此基础上，通过概念、逻辑、物理三个层次逐步细化，才能保证模型既贴合业务又具备高性能。
2.1 数据模型三要素
三要素是所有数据建模方法（ER、维度、NoSQL）的共同基础。下表从定义、符号、工程示例三个维度进行对比：
| 要素 | 定义 | ER 图符号 | 工程分析平台示例 |
|---|---|---|---|
| 实体 | 业务中可独立标识的事物 | 矩形框 | 试验件、传感器、测试任务、数据文件 |
| 属性 | 实体拥有的特征或状态 | 椭圆框 | 试验件编号、传感器型号、采样频率 |
| 关系 | 实体之间的业务关联 | 菱形框 + 连线 | 试验件“包含”传感器（1:N） |
工程避坑提示： 在工程分析平台中，属性最容易出现“大宽表”陷阱——将多个实体的属性合并到一张表中。例如把传感器校准参数直接塞进数据文件表，导致更新异常。正确的做法是：每个实体独立成表，通过关系关联。
2.2 概念模型：业务视角的“第一张图”
概念模型完全脱离技术实现，只关注业务领域中的核心实体和业务规则。它面向业务分析师和领域专家，使用实体-关系图（ERD）或UML 类图表达。
- 目标：统一业务术语，消除歧义。
- 产出物：实体清单、实体间业务关系描述、关键业务规则。
- 工程分析平台示例：“一个试验项目包含多个测试任务，每个任务关联一组传感器，传感器产生原始数据文件。”
建模原则：概念模型阶段不要考虑主键、索引、存储引擎。如果业务专家看不懂，说明模型太“技术化”，需要重构。
2.3 逻辑模型：技术中立的“详细设计图”
逻辑模型在概念模型基础上，增加属性、主键、外键、数据类型、约束，但依然独立于具体的数据库产品。它是数据架构师与开发团队之间的“契约”。
- 关键活动：属性规范化（达到 3NF）、定义候选键与主键、建立关系基数（1:1、1:N、M:N）。
- 工程分析平台示例：“传感器实体包含 sensor_id（主键）、sensor_type、install_date、calibration_date；与测试任务通过 task_id 外键关联。”
| 对比维度 | 概念模型 | 逻辑模型 |
|---|---|---|
| 抽象层次 | 高（业务语义） | 中（技术中立） |
| 包含属性 | 仅关键属性 | 全部属性 + 数据类型 |
| 主键/外键 | 不体现 | 明确标识 |
| 规范化 | 不要求 | 通常 3NF |
| 受众 | 业务专家 | 数据架构师、开发人员 |
常见误区：逻辑模型阶段过早引入数据库特性（如分区键、聚簇索引、引擎选择），会污染模型的中立性。逻辑模型应能在 MySQL、PostgreSQL、DuckDB 之间无缝切换。
2.4 物理模型：面向实现的“施工蓝图”
物理模型将逻辑模型映射到具体的数据库平台，考虑存储结构、索引策略、分区方案、数据压缩、物化视图等性能因素。它是 DBA 和运维团队的操作依据。
- 工程分析平台典型物理设计：
- 分区策略：按时间分区（如 test_date），便于历史数据归档。
- 索引设计：对 sensor_id、task_id 建 B-tree 索引；对时间戳建 BRIN 索引（PostgreSQL）。
- 存储引擎：高频写入场景使用列存引擎（ClickHouse、DuckDB）；事务场景使用行存引擎。
性能与规范权衡：物理模型允许反规范化——例如在数据文件表中冗余存储传感器型号，避免每次查询都 JOIN。但必须通过文档或版本注释记录反规范化的理由，防止后续维护者误解。
2.5 分层设计核心原则
- 逐层细化，不可跳跃：概念模型未评审通过，不进入逻辑模型；逻辑模型未定稿，不进入物理模型。
- 每层独立评审：概念模型由业务专家签字；逻辑模型由架构组评审；物理模型由 DBA 审核。
- 版本关联：三层模型使用同一版本号（如 v2.1.0），确保可追溯。
- 逆向同步：物理模型变更（如新增索引）必须回写到逻辑模型文档，避免模型与实现脱节。
工程分析平台最佳实践：使用
dbdocs 或 SchemaSpy 自动从物理 DDL 生成逻辑模型文档，再人工补充业务描述，实现“物理→逻辑”的半自动同步。