Javaweb项目er图设计

 Javaweb项目介绍:OnlineShopping

ER图设计遵循三大范式:

第一范式:要求任何一张表必须有主键,每一个字段原子性不可再分;

第二范式:建立在第一范式的基础之上,要求所有非主键字段完全依赖主键,不要产生部分依赖(用一张表中同时存有学生与老师的关系来理解;)

第三范式:建立在第二范式的基础之上,要求所有非主键字段直接依赖主键,不要产生传递依赖;

设计数据库表的时候,按照以上范式进行,可以避免表中数据的冗余,空间的浪费。

以下是三大范式对应着表关系的应用:

  • 多对多,三张表,两个外键【第二范式 联合主键的情况】

  • 一对多,两张表,多的表加外键【第三范式】

  • 一对一,外键唯一

本项目的ER图设计很简单,两个最主要的表是用户表和商品表。辅助表是订单表、购物车表。字段名要避开一些关键字,不仅仅是SQL语言的关键字,还包括后端语言(Java、Go)、前端Ajax的关键字(如:order、status)

用户表和商品表的关系是一对多,即一个用户可以上传多个商品,但一个商品只能被一个用户所上传,所以我们需要在商品表中建立外键,关联用户的id。

商品表与购物车表的关系是多对多,即一个商品可以被添加到多个购物车当中,一个购物车中可以添加多个商品,所以我们需要建立一个商品和购物车的关系表,其中两个字段分别关联商品Id和购物车Id。

商品表与订单表的关系也是多对多,即一个商品可以被多个用户所购买产生订单信息,这里的一个商品并不是指的一个抽象的商品名,而是指一个具体的商品实体,即一个商品可以有多个数量。一个订单中也有可能包含多个商品,用户在购买的时候,将多个商品一起进行购买,比如用户一次性购买了所有购物车中的商品信息。所以需要建立一个订单与商品的中间表,表示二者中间的关系。

在进行数据库设计的时候,不要过分地追求数据库的低冗余,有时候数据冗余是可取的,具体看实际的需求。需要说明的是:数据库设计的三大范式是理论上的,实践和理论有时候有偏差,最终的目的都是为了满足客户的需求。在数据库设计的时候,有时候会拿冗余换执行速度,因为在sql中,表和表之间连接次数越多,执行的效率越低。有的时候在数据库设计的时候可能会故意冗余,主要是为了减少表的连接次数,这样做也是合理的,并且对于开发人员来说,sql语句的编写难度也会降低。

为加深读者的印象,以本项目为例:现提出一个需求:我们需要根据商家的Id,去查找其商品被购买的记录;

正常设计的话,用户与商品的关系是一对多,我们需要在商品表中设计一个字段merchantId来表示商家的Id,这一个Id,使用外键关联到对应的用户Id上。而其他地方,就不应该出现表示商家的信息了。

从ER图中我们可以看到,如果其他地方不再出现商家信息,我们需要先获取订单的id,再拿着订单的id去在商品和订单关系表中去查看对应的商品id,在拿着商品的id去商品表中查询商家的id是否与所要查询的商家id一致。这一个过程相当于多表联查,查询了三个表,具体的SQL语句如下:

select * from merchandise left join order_merchandise left join `order` on 
`order`.id = order_merchandise.orderId on merchandise.id = order_merchandise.merchandiseId 
where merchandise.merchantId = 1 order by purchaseDate;

SQL语句过于复杂,并且查询效率低,这时候如果我们在订单与商品表的字段上添加与商品Id对应的商家Id,这时候我们的SQL语句将变得简单,且便于查询到的数据进行封装的操作;

一旦数据库设计不太合理,后端人员就需要使用大量的复杂的逻辑去弥补数据库设计的漏洞,不利于后端程序的开发。所以在进行开发时,一旦发现数据库设计有不合理之处,就需要想清楚,及时进行修改。数据库的设计是一个技术活,要多看、多分析、多练;一个合理的数据库,可以省去后端大量的麻烦,大大提高开发效率。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值