数据库设计问题
设计表的时候需要考虑的问题
- 保存哪些数据
- 如何保证数据的正确性，增删改的时候该怎样进行约束检查
- 如何降低数据的冗余度
- 设计表结构需要遵循的方向：冗余较小、结构合理
范式
概述
- 在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的 级别 。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
- 范式英文Normal Form，简称NF。是范式是关系型数据库理论的基础。也是我们在设计数据库结构过程中所要遵循的规则和指导方法。
范式类别
- 目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
- 设计范式级别越高，冗余度就越低。同时高阶范式一定符合低阶范式的要求。
- 一般来说达到第三范式即可。
相关概念
范式的定义会使用到主键和候选键，数据库中的键由一个或多个属性组成。数据库表中常用的几种键和属性定义如下
超键：能唯一标识元组的属性集候选键：如果超键不包含多余的属性，那么这个超键就是候选键主键：用户可以从候选键中选择一个作为主键外键：如果数据表R1中的某属性集不是R1的键，而是另一个数据表R2的键，那么这个属性集就是R1表的外键主属性：包含在任一候选键中的属性称为主属性。非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性。
- 案例
第一范式
表中的每一个字段都具有原子性，也即表中的字段不能再被拆分
案例
第二范式
在满足第一范式的基础上，还需要满足数据表中的每一条记录都是可唯一标识的。而且所有的非主键字段，都必须完全依赖主键，不能只依赖主键的一部分
案例
(球员编号,比赛编号)联合主键只能唯一标识得分字段
其他字段都只需要部分依赖(球员编号,比赛编号)即可唯一标识
假设使用(球员编号,比赛编号)存在的问题
第三范式
在第二范式的基础上，确保数据表中每一个非主键字段都和主键字段直接相关。也即表中所有非主键字段不能依赖其他非主键字段。该规则的意思是所有非主键属性之间不能欧依赖关系，必须相互独立。
案例
小结
关于数据表的设计，有三个范式需要遵守
- 第一范式，保证每个字段原子性
- 第二范式，保证非主键字段和主键字段完全依赖，尤其是联合主键
- 第三范式，保证非主键字段和主键字段直接相关，而不是间接相关。
范式的优点：
- 消除数据表中的数据冗余
范式的缺点：
- 随着范式等级越来越高，设计出来的数据表就越多、约精细，导致可能查询的时候需要关联多张表
实际使用中，并不一定需要完全符合这些标准。需要根据具体场景具体分析
巴斯范式
- 对第三范式中设计规范要求更高，使得数据表冗余更小。若一个数据表达到了第三范式并且只有一个候选键，或者每个候选键都是单属性，则该关系自然达到了BC范式。
第四范式
第五范式
ER模型
- ER（Entity-Relationship）模型也称为实体关系模型，是用来描述现实生活中客观存在的事物、事物的属性以及事物之间关系的一种数据模型。在设计阶段，通常使用ER模型来描述信息需求和信息特性，帮助我们理清业务逻辑，从而设计出优秀的数据库。
ER模型三要素：实体，属性和关系
- 实体 ，可以看做是数据对象，往往对应于现实生活中的真实存在的个体。在 ER 模型中，用 矩形 来表示。实体分为两类，分别是 强实体 和 弱实体 。强实体是指不依赖于其他实体的实体；弱实体是指对另一个实体有很强的依赖关系的实体。
- 属性 ，则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用 椭圆形 来表示。
- 关系 ，则是指实体之间的联系。比如超市把商品卖给顾客，就是一种超市与顾客之间的联系。在 ER 模型中用 菱形 来表示。
关系类型：
- 一对一 ：指实体之间的关系是一一对应的，比如个人与身份证信息之间的关系就是一对一的关系。一个人只能有一个身份证信息，一个身份证信息也只属于一个人。
- 一对多 ：指一边的实体通过关系，可以对应多个另外一边的实体。相反，另外一边的实体通过这个关系，则只能对应唯一的一边的实体。比如说，我们新建一个班级表，而每个班级都有多个学生，每个学生则对应一个班级，班级对学生就是一对多的关系。
- 多对多 ：指关系两边的实体都可以通过关系对应多个对方的实体。比如在进货模块中，供货商与超市之间的关系就是多对多的关系，一个供货商可以给多个超市供货，一个超市也可以从多个供货商那里采购商品。再比如一个选课表，有许多科目，每个科目有很多学生选，而每个学生又可以选择多个科目，这就是多对多的关系。
规范建议
若有收获，就点个赞吧
0 人点赞
