数据库数据表设计的引路人

数据库数据表设计的引路人

引言✨🌟帅的人都先看我

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

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

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 第二步：E-R图转换为关系模型（将关系细分为数据表）

选购关系转换为选购表：（商品号、订单号、单价、数量）

属于关系转换为订单表：（订单号、用户号、订单日期、订单总价、订单状态）

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

3 第三步：进行规范化处理（三范式）

1NF：每列不可再分，原子性

满足

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

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

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

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