数据库设计三范式

数据库设计最经典的三大范式。

一、字段不可分

故名思议,每个数据库表的字段都是不可分割的,都是原子结构。但是什么才算是原子结构?这就和具体的情况有关,比如地址,如果我们的项目要求只需要一个简单地址信息,那么这个地址就是原子性的,但是如果我们需要根据所在省,所在市,所在街道进行操作时,这个地址信息就不能简单是一个地址信息了。它就不是原子性的。这就是我们所说的相对性。简单来说,如果我们业务不要求某个字段内部详情,就可以单独把它当作一个独立的字段。

二、不能部分依赖主键

这句话就是说,表的每个字段都依赖主键,但是不能只依赖主键的一部分,比如(A1,A2,A3,A4)这个表,其中(A1,A2)是表的主键,但是A3独立依赖于A1,即A1->A3,那么这张表就不符合数据库的第二范式。可以把这张表拆成(A1,A2,A3),(A1,A4),虽然看起来冗余了,但是实际上是消除冗余了。因为不要只单单看这样的结构,比如在之前那个表有10000行数据,那么所占用的容量就是10000(A1+A2+A3+A4),但是对于我们已经拆分出来的那两张表所占容量是10000(A1+A2+A3) + n*(A1+A4),注意这里n小于10000,注意A1,A2合并起来才确定10000个不同的组合,平均下来就是A1就只有100个,那么显而易见满足第二范式消除了冗余。冗余主要是体现在可能有很多字段包含相同信息。

同时除了消除数据冗余,还有以下好处。
1. 消除删除异常。对于开始那张表,如果删除所有的A2信息,那么A1的信息也全部删除了。这不是我们想要的。
2. 消除插入异常。比如我们要插入A1,A4这两个字段,但是不存在A2信息,那么就无法写入数据库。
3. 消除更新异常。如果要调整A1所对应的A4信息,由于原表可能有很多这样的对应关系,那么所有行都要调整。这样做很麻烦。如果不小心就可能造成数据的不一致。

三、不能传递依赖

这个和第二范式有些不同。第二范式是这样的非主键字段A,主键B,C不能有B->A,但是对于第三范式就是不能有非主键字段D,使得(B.C)->D->A,这样A就传递依赖于主键。注意这里传递的对象是非主键对象。第二点也可以写成传递依赖的关系如(B,C)->B->A,但是传递的对象是主键的一部分。
不满足第三范式同样也会出现这样那样的问题。
这里的例子我就举一个具体的例子。
学号, 姓名, 年龄, 所在学院, 学院联系电话,学院地点,关键字为单一关键字"学号"; 
由于学号->所在学院->(学院联系电话,学院地点),构成传递依赖,不符合第三范式。
1. 数据冗余,比如有100个同一学院的学生,那么所在学院, 学院联系电话,学院地点就必须重复出现100次,造成数据冗余
2. 删除异常,如果删除所有学号信息,那么学院地址信息和联系电话也同样被删除了。
3. 插入异常,如果我们想插入某个学院的地址联系电话信息,但是该学院没有学号,那么就无法插入
4. 更新异常,如果我们要更新某个学院的联系电话,可想而知复杂度。

数据库的三大范式在关系型数据库设计中是最重要的,虽然后面还有第四、第五范式。。。但是在我们日常所面对的项目中,所用到的不多,大家只要理解数据库这三大范式就可以解决数据库设计多的大部分问题。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值