数据库设计——三范式学习理解

什么是范式?

数据库设计中,需要遵循一定的规则才能避免数据的冗余,这些规则实际上限制的是表与表、表与属性之间的关系。这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

1.第一范式(1NF)

第一范式是指数据表中的每个字段必须是不可拆分的最小单元,也就是确保每一列的原子性。
举个例子,某省的投档线公布表:

院校代码 科类 院校名称 投档分
0019 理工 吉林大学 538.106123198
1000 理工 北京大学医学部 657.141142258
1001 文史 北京大学 633.127139227

很明显,这个投档线字段包括了总分、数学语文和英语,这个字段可以拆分为另外四个字段,所以这种设计不遵循第一范式。

2.第二范式(2NF)--先要满足第一范式

第二范式是指每一列必须要有主键,并且非主键列必须依赖于主键,确保了表关系的唯一性。

我们来简单理解,这句话的意思,首先就是要有主键,这很简单,很好理解,同一张表中,不能有任意两行的主键是相同的,这也就确保了每一行的主键唯一性。那后面一句话,非主键列必须依赖于主键,什么意思?首先,需要指出的是,所谓的依赖,可以通俗简单的理解为相关。也就是说,这一行数据已经依靠主键唯一确定了一组信息,那么该行的非主键数据必须是和主键是有关的,否则,就失去了意义,或者说,就产生了没有意义的列。所谓的表关系的唯一性,其实就是在说,这张表的结构所描述的只能是一种关系,无关的信息不应该出现。

举个例子,我们来看这样一张表:

表的显示如下:(作为例子,我只插入了一行数据)

仔细看这张表,有个很明显的问题,主键是学号,唯一标识了一位学生,但是在该表的列关系中却出现了课程名称和课程学分。这个表明显说明了两个事务:学生信息, 课程信息; 这两者,显然不应该是出现在一张表中的。注意,这张表是学生信息表,不要理解成学生选课的信息表。

上述例子,可能理解有些抽象,我们在来看一个更加极端的例子。

假如,现在我们有个学生表,学号,姓名,性别,商品单价。

现在,是不是一眼就看出来,哪里有点不对劲,学生表中的商品单价是什么鬼?哈哈,如果你能想到这个问题,说明你其实已经理解了第二范式,很显然,商品单价跟这个表关系想要描述的学生信息毫无关系,怎么能出现在一张表中呢?注意,这个简单的例子只是很极端的帮助理解第二范式。

3.第三范式(3NF)--先要满足第二范式

第三范式就是每一列非主键数据必须直接依赖主键,而不能存在间接依赖(传递依赖)。

这句话怎么理解呢?我们还是看我们第二范式介绍的时候,那个例子,我们当时说的是我们建立的学生信息表,所以课程名称和课程学分的信息和主键不相关。那么,我们此时改变逻辑,我们来看下面的例子:

我们上述简单理解为学生的选课信息,此时的行数据表示该学号的学生选择了哪一门课程。比如例子中所说信息表示,55161008这名学生,选择了数据库的课程,课程学分为4分。

哎,乍一看,这不是挺合理的吗?我们仔细想一下,学分和学号的关系是依托于课程的,也就是说学分与学号并没有直接的关系

换句话说,课程的学分数据是课程的相关信息,应该出现在描述课程信息的那张表中,出现在这里是冗余的。

我们例子中出现的所谓的间接相关:表关系的含义是,学号代表的那名学生选择了某一课程,这个课程的学分是多少分;

很明显,这不是直接关联的,因为课程学分本身跟学生毫无关系。

总结:

这里只是很简单的,阐述了三范式的含义和举出了例子进行基础的理解,其实无论是什么范式,都是为了更好的设计数据库,更好的管理表关系。所以,我们在数据库关系建表的时候,尽可能的应该结合实际更好的去利用这些范式。

猜你喜欢

转载自blog.csdn.net/romantic_jie/article/details/100668439