关系(二维表)的设计规范,范式
范式:Normal format是指对表结构的要求
目的:1.规范结构 2.减少数据冗余
第一范式 1NF
要求每个字段具有
原子性,
原子性是指每个字段不能在分了,
什么叫不能再分了呢?
比如说
比赛id | 比赛名称 | 教练 | 参与人员 | 开始时间结束时间 |
1 | 游泳 | Helios | 小明 | 一点~三点 |
2 | 跳水 | Helios | 小红 | 两点~五点 |
3 | 蛙跳 | Helios | 小张 | 一点~八点 |
像上面的开始时间和结束时间就是没有原子性,因为如果查表的时候还是可以只是查结束时间和开始时间,这样的话就不能使数据库方便了;
把上面的表换位原子性表为:
比赛id | 比赛名称 | 教练 | 参与人员 | 开始时间 | 结束时间 |
1 | 游泳 | Helios | 小明 | 一点 | 三点 |
2 | 跳水 | Helios | 小红 | 两点 | 五点 |
3 | 蛙跳 | Helios | 小张 | 一点 | 八点 |
第二范式2NF
要求每个字段对主键不能
部分依赖,
什么是部分依赖:针对于联合主键来说的,如果对于单一的主键来说是不会出现部分依赖的,因为那是完全的依赖主键(应该叫完全依赖),也就是说一个数据表中只能保存一种数据,不能把多个数据保存到一个数据表中;
比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。
订单信息表
这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。
这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。
第三范式 3NF
第三范式要求每个字段个主键是直接相关,不能是间接相关(
不能出现传递性)
传递性是什么:要求每个只能和主键相关联,不能字段依靠字段,然后和主键相关
id | 姓名 | 性别 | 比赛项目 | 举办方 |
---|---|---|---|---|
1 | 小红 | 女 | 游泳 | Helios |
2 | 小钟 | 男 | 跳远 | Helios |
3 | 小张 | 男 | 蛙跳 | Helios |
像上面的表所示:当姓名确定了,性别就一定确定了,性别是依靠姓名的;当比赛项目确定了,举办方就确定了,举办方是依靠比赛项目的;
这样就会出现了传递依赖 性别-->姓名-->id 举办方-->比赛项目-->id
在这种情况下,就能多建几张表,
将独立的实体信息用独立的关系(二维表)来表示
姓名id | 姓名 | 性别 |
11 | 小红 | 女 |
21 | 小钟 | 男 |
31 | 小张 | 男 |
项目id | 比赛项目 | 举办方 |
12 | 游泳 | Helios |
22 | 跳远 | Helios |
32 | 蛙跳 | Helios |
id | 姓名id | 项目id | ||
1 | 11 | 12 | ||
2 | 21 | 22 | ||
3 | 31 | 32 |
这样就可以把 上面的那一个大表,划分为三个这样的字表,并且都与相应的主键直接相关
总的来说就是每个实体建立一个表,每个表有一个自己的主键;