第4章数据库设计（概念结构）

4、数据库设计（概念结构）：E-R图设计、实体定义、属性定义、关系定义

好，咱们进入数据库设计的核心环节——概念结构设计。说白了，就是画E-R图，把现实世界里的摩擦焊工艺，翻译成数据库能理解的“语言”。这一步要是走偏了，后面建表、写查询都会很别扭。我当年带第一个团队做工艺数据库时，就吃过这个亏，E-R图没画透，结果后期改了三次表结构，那叫一个折腾。

先聊聊实体。实体就是我们要记录的核心对象。在摩擦焊这个场景里，我归纳了四个核心实体：材料对、设备、参数集、焊接结果。你想想看，一次焊接实验，不就是“用什么材料、在哪台设备上、设了哪些参数、焊出来什么结果”吗？

材料对：这是焊接的“原料”。比如45钢焊304不锈钢，或者铝合金焊铜。注意，是“一对”，不是单种材料。我习惯把母材1和母材2分开记录，因为顺序有时候会影响工艺。
设备：每台焊机都有自己的“脾气”。同一套参数，换台设备可能效果就不同。所以设备信息必须独立出来。
参数集：这是工艺的核心。摩擦压力、时间、转速、顶锻力……几十个参数组合在一起，才构成一个有效的参数集。
焊接结果：最终的成绩单。包括接头强度、断裂位置、变形量、金相评级等。

个人经验： 我建议把“材料对”和“参数集”分开。有人图省事，把材料信息直接塞进参数集里。结果后来想查“所有45钢的工艺”，SQL写得那叫一个痛苦。分开后，查询灵活多了。

实体是骨架，属性才是血肉。每个实体都需要一组属性来描述它。嗯，这里要注意，属性要选那些“有业务价值”的，别什么都往里塞。

避坑指南： 我曾经把“检测日期”放在参数集里，觉得“反正是一次实验”。后来发现，同一个参数集可能在不同日期重复验证，日期应该跟着结果走。属性放错位置，后期数据会乱成一锅粥。

实体之间怎么关联？这是E-R图的核心。我总结了三组关键关系：

为什么会这样设计？你想想看，如果参数集和结果是一对一，那每次实验都得新建一个参数集，重复数据会爆炸。一对多，才能做统计分析。

光说不行，得画出来。下面这张SVG图，展示了四个实体以及它们之间的连接关系。矩形代表实体，菱形代表关系，连线上的“1”和“N”表示一对多。

这张图看着简单，但它是整个数据库的“宪法”。后续所有表结构、索引、查询，都得遵循这个关系。我每次做新项目，都会先把E-R图贴在白板上，团队评审通过再动手建表。

注意： 关系不要画得太复杂。有人喜欢把“材料对”和“设备”直接连起来，觉得“设备加工材料对”。但中间隔着参数集呢，直接连会丢失信息。保持E-R图的简洁性，每个关系都要有业务含义。

数据库设计，尤其是概念结构，最忌讳“贪多求全”。我见过有人把“操作工姓名”、“车间温度”都塞进实体里。不是说这些不重要，而是它们属于“环境信息”，可以单独建一个“实验环境”实体，或者干脆用备注字段。核心实体越精简，后期维护越轻松。

另外，属性类型要选对。比如“金相评级”用整数，别用字符串。虽然“1级”和“1”看起来差不多，但数据库排序时，字符串的“10”会排在“2”前面，你会疯掉的。

好了，概念结构设计就聊到这儿。E-R图是数据库的蓝图，画好了，后面建表、写SQL都顺风顺水。画不好，返工是迟早的事。记住我这句话：先想清楚关系，再动手写代码。