数据库数据表设计思想一

数据库数据表设计思想一

引言✨帅的人都先看我

数据库设计一般交由后端开发人员直接设计(无论是否有经验),而不会让经验丰富的开发人员包揽(做评审即可)。

  1. 数据没必要一次完整的设计出来,开发过程中,难免会对数据库进行调整的,保证数据的骨架没有问题 【 增删字段、添加中间表、加视图都不会造成多大的影响 】
  2. 数据库设计是后端部分需求转换的过程(一般业务),类比原型设计是前端部分需求转化的过程,通过数据库分库、分表就能大致划分后端功能结构,如果后端开发人员跳过了数据库的设计,大概率会出现分不清功能结构的状况,只能根据页面原型猜测需要哪些接口,这种看到一个功能开发一个接口的工作模式,大多数情况会出现开发进度不可控、开发了多余的接口、漏写接口的问题,故数据库设计是每个后端人员都必须掌握的技能

1 设计数据库流程

数据库数据表设计思想一_第1张图片

1 三步走

  1. 确定实体及其关系:实体(现实世界数据)转换为信息模型(E-R)
  2. E-R图转换为关系模型()
  3. 进行规范化处理(三范式)

2 三范式介绍(不需要必须都满足)

  1. 第一范式(1NF):表中的每个字段都应是原子性的,不可再分。这意味着每个字段不应包含多个值或数组。
  2. 第二范式(2NF):表中的非主键字段应完全依赖于主键。如果一个表具有复合主键,那么非主键字段应该依赖于整个复合主键,而不是部分主键。
  3. 第三范式(3NF):除了满足第二范式的要求,还要求非主键字段之间不应该存在传递依赖。也就是说,非主键字段不应该依赖于其他非主键字段。

3 不需要三范式都满足的情况举例(因为业务需要而添加冗余数据)

1 订单表

在电子商务中,订单通常包括客户信息、商品信息和交易信息。如果您严格满足三范式,可能需要将这些信息分散存储在不同的表中,并使用外键进行关联。但为了提高查询性能,您可能会考虑将一些客户信息和商品信息冗余存储在订单表中

2 博客评论表

假设您正在设计一个博客网站的数据库,其中有博客文章和评论。评论通常会关联到特定的博客文章,如果您严格满足三范式,可能需要在评论表中存储博客文章的主键,而不是直接将博客文章标题或内容存储在评论表中。但为了提高查询性能和减少联接操作,您可能会考虑在评论表中冗余存储博客文章的标题或内容

2 案例分析

  1. 用户注册:输入用户号、用户名、密码、性别、住址、邮箱及电话进行注册,注册成功以后就可以按产品的分类浏览网站

  2. 商品管理:为管理员所用,管理员可以增加商品分类,可以为每个分类增加商品,其中商品包括商品号、商品名、商品分类、市场价格、当

    前价格、数量及商品介绍

  3. 用户订购商品:当用户看中某个商品时,可以加入购物车;当用户选择完毕时,就可以购买下单了。购买涉及订单、订单明细,其中,订单包括订单号、订单日期、订单总价、订单状态等信息;而对于每个订单,有订单明细表,列出了所购商品号、单价和数量

1 第一步:根据商城业务逻辑建立E-R图

实体:①用户、②商品、③订单

关系:当用户需要购买商品时,需要下单,此时订单与用户发生关联。用户与订单是一对多的联系
下单时,订单与商品发生关联,订单与商品是多对多的联系

数据库数据表设计思想一_第2张图片

2 第二步:E-R图转换为关系模型(将关系细分为数据表)

选购关系转换为选购表:(商品号、订单号、单价、数量)

属于关系转换为订单表:(订单号、用户号、订单日期、订单总价、订单状态)

数据库数据表设计思想一_第3张图片

此时存在两个订单表,为满足对应关系,保留包含用户号的订单表即可

数据库数据表设计思想一_第4张图片

3 第三步:进行规范化处理(三范式)

1NF:每列不可再分,原子性

满足

2NF:非主键字段完全依赖主键字段

商品表的商品分类字段不依赖与商品表,故将划分出商品分类表(分类号、分类名称),使用分类号代替原先的商品分类字段即可

3NF:非主键字段不存在传递依赖

数据库数据表设计思想一_第5张图片

数据库数据表设计思想一_第6张图片

得出最终版的数据库关系模型

数据库数据表设计思想一_第7张图片

你可能感兴趣的:(mysql,数据库)