构建EER图时如何判定user与friend、message表的关联类型

先澄清常见认知误区 #

EER的二元关联计数从来不存在「1:2」的表述——你产生这个误判，本质是把同一对实体间两条独立的、带不同语义角色的关联线合并成一条做计数了。关联判定的核心逻辑很简单：两个实体之间，每存在一个明确的语义角色，就对应一条独立的连线，单独计算两边的基数，不要混算。 #

针对你这套表结构的关系拆解 #

默认你的基础配置符合常规设计：user表主键为user_id，friend、message表的两个外键request_from_id、request_to_id均指向user表的user_id。

1. user 与 friend 表的关联
   两者之间存在两条完全独立的一对多（1:N）关联，不存在合并为单一关系的说法：
   • 第一条关联：user作为好友申请的发起方，对应多条friend表中request_from_id匹配的记录；反过来单条friend记录的发起者只能是一个user，因此这条连线的基数是 user侧为1，friend侧为N，连线需要标注角色「发起好友申请」
   • 第二条关联：同一个user作为好友申请的接收方，对应多条friend表中request_to_id匹配的记录；反过来单条friend记录的接收者也只能是一个user，这是另一条独立的 1:N 连线，标注角色「接收好友申请」
2. user 与 message 表的关联
   逻辑和friend表完全一致，同样是两条独立的一对多关联：
   • 第一条：user作为消息发送方，对应多条message表中匹配request_from_id的记录，1:N，标注角色「发送消息」
   • 第二条：user作为消息接收方，对应多条message表中匹配request_to_id的记录，1:N，标注角色「接收消息」
     顺带提一句，你现在friend和message表用了完全一样的两个外键名request_from_id、request_to_id，后续做关联查询很容易搞混表来源，建议message表的对应字段改成sender_id、receiver_id，语义更清晰。

EER图搭建的实操注意事项 #

• 绝对不要把两个外键合并到同一条连线上，必须拆成两条独立的关联线，每条线明确标注对应的语义角色、对应外键、以及两边的基数
• 基数标记如果用乌鸦脚记号，对应每条连线的user端是单竖线（代表强制一对一的约束关系），friend/message端是多爪标记（代表多对一的反向关系）
• 如果你设计的friend表是存储双向好友关系（即互加好友仅存1条记录），通常会给两个外键加联合唯一索引，这个约束不改变关联基数的判定，只是用于避免产生重复好友关系的脏数据。

常见踩坑提醒：很多新手会因为两个外键属于同一张关联表，就把关联合并成1:2的线，最后画出来的图完全不符合EER规范，后续写多表关联查询、配置外键约束的时候很容易出现方向混乱的问题。

内容的提问来源于stack exchange，提问作者kowal20