📚 课程目录第4章材料数据库概念模型与逻辑模型

4. 材料数据库概念模型与逻辑模型

在材料数据库建设中，概念模型回答“系统里有哪些对象、它们之间是什么关系”，逻辑模型回答“这些对象如何落到表、字段、主外键和约束上”。两者不是文档装饰，而是决定后续数据能否被正确录入、关联查询和扩展的骨架。若跳过概念建模直接建表，常见后果是性能数据与工艺条件脱节、同一材料在不同表中重复出现、查询“某工艺下强度大于某值的材料”时不得不写大量手工拼接。

一、从材料对象到实体：概念模型的识别方法

概念模型的核心是实体、属性和联系。材料领域最容易被误判的是“材料”本身：它既可以是具体牌号（如 Ti-6Al-4V），也可以是材料类别（如钛合金）。建议把材料作为独立实体，用 material_id 唯一标识，属性包括名称、牌号、类别、标准体系、化学成分范围等。与之并列的实体通常有：性能（performance）、工艺（process）、结构（structure）、测试条件（test_condition）和数据来源（source）。

关键判断是：性能值不能直接挂在材料上。同一 Ti-6Al-4V 在退火态与固溶时效态下屈服强度差异显著，因此“性能”必须与“工艺状态”和“测试条件”共同构成一次观测记录。这就是材料-性能-工艺-结构关联表达的起点：材料—工艺—结构—性能四者通过“观测/试验记录”这一联系实体绑定，而不是两两直接相连。

二、逻辑模型：从联系实体到关系表

概念模型中的“观测记录”在逻辑模型中通常落为一张事实表 observation，其主键为 obs_id，外键分别指向 material、process、structure、condition、source。性能值有两种落法：一是把数值直接放在 observation 表（适合性能类型少、查询简单的场景）；二是拆出 observation_performance 明细表，每行一个性能类型和数值（适合性能类型多、需要灵活扩展的场景）。后者更符合材料数据“同一观测可测多个性能”的实际，推荐作为默认逻辑结构。

-- 逻辑模型核心表（示例，字段为教学简化）
CREATE TABLE material (
  material_id   VARCHAR(32) PRIMARY KEY,
  name          VARCHAR(64) NOT NULL,
  grade         VARCHAR(32),
  category      VARCHAR(32),
  standard      VARCHAR(64)
);

CREATE TABLE process (
  process_id    VARCHAR(32) PRIMARY KEY,
  process_type  VARCHAR(32),   -- 退火/固溶/时效/轧制
  temperature_C DECIMAL(6,1),
  duration_min  DECIMAL(6,1),
  cooling_rate  VARCHAR(16)
);

CREATE TABLE structure (
  structure_id  VARCHAR(32) PRIMARY KEY,
  phase         VARCHAR(64),
  grain_size_um DECIMAL(6,2),
  texture       VARCHAR(64)
);

CREATE TABLE observation (
  obs_id        VARCHAR(32) PRIMARY KEY,
  material_id   VARCHAR(32) REFERENCES material(material_id),
  process_id    VARCHAR(32) REFERENCES process(process_id),
  structure_id  VARCHAR(32) REFERENCES structure(structure_id),
  condition_id  VARCHAR(32) REFERENCES test_condition(condition_id),
  source_id     VARCHAR(32) REFERENCES source(source_id)
);

CREATE TABLE observation_performance (
  obs_id        VARCHAR(32) REFERENCES observation(obs_id),
  perf_type     VARCHAR(32),   -- yield_strength / elongation / density
  value         DECIMAL(12,4),
  unit          VARCHAR(16),
  PRIMARY KEY (obs_id, perf_type)
);

这里有一个容易忽略的约束：observation_performance 的主键是 (obs_id, perf_type)，保证同一观测下同一性能不重复录入；若同一性能有多次测量，应增加 replicate_no 字段，而不是覆盖旧值。单位必须与数值同表存储，避免“数值是 MPa 还是 ksi”只能靠人工记忆。

三、面向查询的模型优化

概念与逻辑模型正确，不等于查询高效。材料数据库最常见的查询是“给定材料类别 + 工艺类型 + 性能阈值，返回满足条件的材料与观测”。若每次都在 observation 与 observation_performance 之间做多表连接再过滤，数据量到百万级后响应会明显下降。优化方向有三类：

索引优化：在 observation(material_id)、observation(process_id)、observation_performance(perf_type, value) 上建组合索引，使“按性能类型和阈值过滤”能走索引范围扫描。
反规范化宽表：对高频查询，可建立物化视图或汇总表 mv_material_property，把 material_id、process_type、perf_type、value、unit 预先连接好，查询时只扫一张表。代价是写入时需要刷新，适合读多写少的材料检索场景。
单位归一化：在写入阶段把强度统一为 MPa、温度统一为 ℃，避免查询时对 value 做单位换算导致索引失效。归一化规则应记录在 source 或独立 unit_rule 表中，保证可追溯。

判断优化是否有效的直接方法：对同一查询分别执行 EXPLAIN，观察是否出现全表扫描（type=ALL）或临时表排序；若优化后 type 变为 ref/range 且 rows 显著下降，说明索引或宽表生效。示例数据量建议用 10 万条观测记录做验证，而不是仅用几十条测试数据。

四、一个可执行的建模检查清单

完成概念与逻辑模型后，可用下面这份清单自查，避免把问题留到数据录入阶段：

检查项	合格标准	常见问题
材料唯一性	material_id 唯一，牌号+标准可定位	同一牌号因来源不同重复建行
性能归属	性能值挂在 observation 或明细表，不直接挂 material	把屈服强度直接写成 material 字段
工艺状态可区分	process 表能表达温度、时间、冷却方式	只写“热处理”无法区分退火与时效
结构可关联	structure_id 可空但可追溯	结构信息只写在备注文本中
单位一致	value 与 unit 同表，写入前归一化	同一性能列混用 MPa 与 ksi
查询路径	高频查询有索引或宽表支撑	所有查询都走多表连接

把这份清单与前面的概念图对照使用：图中每个实体和联系，都应在逻辑模型中有对应的表或外键；每个高频查询，都应在逻辑模型中有可用的索引或汇总结构。概念模型保证“数据关系正确”，逻辑模型保证“数据可存可查”，面向查询的优化保证“查得快且结果可解释”。三者缺一，材料数据库就容易退化为一张难以维护的大表。