库存数据库Entity Relationship diagram(ER图)逻辑解读

全部核心实体 #

所有实体均采用单主键设计，主键在图中以下划线标注：

• supplier（供应商）：主键s_id（供应商编号），属性包括s_name（供应商名称）、s_city（所在城市）、s_phone（联系电话），存储所有上游供货方的基础信息
• dealer（经销商）：主键d_id（经销商编号），属性包括d_name（经销商名称）、d_city（所在城市）、d_phone（联系电话），存储中间经销主体的基础信息
• customer（客户）：主键c_id（客户编号），属性包括c_name（客户名称）、c_city（所在城市）、c_phone（联系电话）、c_gender（客户性别），存储下游消费用户的基础信息
• product（产品）：主键p_id（产品编号），属性包括p_name（产品名称）、p_company（生产/品牌方）、p_price（销售单价）、p_quantity（当前库存余量），是整个库存系统的核心流转对象

实体关联关系与业务规则 #

图中所有关联均为多对多关系，符合零售库存的实际业务场景，不存在某类实体独占绑定另一类实体的约束：

• 供应关系（supplies）：连接供应商与产品
  • 业务规则：1家供应商可供应多款产品，同一款产品也可由多家供应商供货
  • 关联属性：supply_date（供货日期），记录单批次供货的发生时间
• 采购关系（purchases）：连接经销商与产品
  • 业务规则：1家经销商可采购多款产品备货，同一款产品也可供货给多家经销商
  • 关联属性：purchase_date（采购日期）、pur_quantity（采购数量），记录单批次经销商进货的时间、进货量
• 订单关系（orders）：连接客户与产品
  • 业务规则：1个客户可下单多款产品，同一款产品也可被多个客户购买
  • 关联属性：order_date（下单日期）、ord_quantity（购买数量）、ord_amount（订单实付金额），记录单条客户订单的交易明细

设计逻辑说明 #

注意纠正之前的理解偏差：purchases对应的是经销商向上游采购备货的内部流转环节，并非客户购买产品的行为，客户购买的所有交易记录都通过orders关联存储。
整个设计覆盖了库存流转的全链路：供应商供货入库→经销商采购备货→客户下单销货，所有跨主体的交易类字段都存在关联关系中，没有把交易属性冗余到实体表内，符合数据库第三范式要求；同时所有实体的主键、外键命名规则统一，后续建表、写查询语句时辨识度高，不容易出现字段混淆问题。

内容的提问来源于stack exchange，提问作者Gourav kr Singh