ER图建模中将Discount Policy设为实体是否合理？

关联关系上设置属性完全符合ER图规范 #

标准陈氏ER模型本身就允许关联关系（Relationship）挂载属性，这类属性不属于关联两端的任何一个实体，专门用来描述两个实体产生关联这个动作本身的特征，是完全合规的建模方式。
你现在把Percentage Discount Based On Policy放在Discount Policy和Bills的关联关系上，设计逻辑是通顺的：这个值记录的是当前这张账单生成时实际生效的折扣比例，属于「这张账单应用了这条折扣政策」这个关联事件的专属快照数据——毕竟后续折扣政策调整时，不能改动历史账单的折扣计算依据，这个属性放在关联关系上，比放在Discount Policy或者Bills实体上更贴合数据的本质含义。

Discount Policy做实体还是Customer Type属性的判断标准 #

不要用「是不是一对一关联」当判断依据，核心看这个折扣规则本身的业务特征：

• 如果折扣政策永远只有「百分比数值」这一个信息，不需要单独配置、没有额外规则、也永远不会出现多个客户类型共用同一条折扣的情况，那完全可以把它简化成Customer Type实体下的discount_percent属性，模型更简洁没有冗余。
• 只要满足下面任意一种情况，保留Discount Policy作为独立实体的设计更合理：
  • 折扣规则未来会扩展：比如要加生效时段、适用商品品类、满减叠加逻辑、折扣上限、启用/禁用状态等
  • 折扣政策有独立生命周期：比如运营可以提前创建新折扣，到指定时间再绑定给对应客户类型，旧折扣归档留痕
  • 折扣政策存在复用可能：比如多个客户类型短期共用同一条折扣规则，后续再拆分调整
  • 需要追溯折扣的调整历史：比如查询某条折扣历史上绑定过哪些客户类型、比例调整过多少次

新手区分实体/属性的实用方法 #

不用纠结抽象概念，拿不准的时候对着三个条件核对，满足任意一个就优先设为实体：

• 这个对象不止一个描述维度：如果只有一个简单的数值/字符串（比如只有一个折扣百分比）就是属性，如果还要存名称、创建时间、规则描述等多个信息就是实体
• 这个对象可以独立存在：比如折扣政策可以先创建，暂时不绑定任何客户类型，就符合实体的特征
• 这个对象会被多个其他对象重复引用：如果多个客户类型可以用同一条折扣，就不要把折扣当某个客户类型的属性
  三个条件都不满足的话，直接设为属性就行，不用过度设计。

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