一般的数据库设计都需要满足三范式,这是最基本的要求的,最高达到6NF,但是一般情况下3NF达到了就可以
一:1NF一范式的理解:
1NF是关系型数据库中的最基本要求,就是要求记录的属性是原子性,不可分,就是属性不能分,这是关系型数据库的基本要求,不满足这个就不能叫关系型数据库了
例如:
讲师 性别 班级 教室 代课时间 代课时间(开始,结束)
韩忠康 Male php0331 102 30天 2013-03-31,2013-05-05
韩忠康 Male php0228 106 30天 2013-02-28,2013-03-30
韩顺平 male Php0228 106 15天 2013-03-31,2013-05-05
上面的代课时间字段设计就不满足原子性,因为它可以再分的,开始时间和结束时间,需要按照下面来设计拆分:
讲师 性别 班级 教室 代课时间 开始 结束
韩忠康 Male php0331 102 30天 2013-03-31 2013-05-05
韩忠康 Male php0228 106 30天 2013-02-28 2013-03-30
韩顺平 male Php0228 106 15天 2013-03-31 2013-04-20
上面的就满足了,但是有些时候也需要去违背这个1NF的设计:在用dede设计cms的时候后台的下载地址是将格式,名称,分辨率这些进行评级在一个属性里面,但是可以看作一个整体,因为这个属性即使分开,那么各个成员的关系不是平等的,但是代课时间是不一样的,比如分为开始时间和结束时间,两个成员的关系基本一样!所以也不矛盾!
二:2NF二范式的理解(需要理解 部分依赖、完全依赖、传递依赖)
2NF是不能有部分依赖,部分依赖的前提条件是有组合主键,就是每条记录是需要一个主键的,这个主键可以是一个单独的属性,但也可以是组合主键,就是由记录的多个属性来唯一确定一条记录,那么只要出现了组合主键就可以产生部分依赖,部分依赖是组合主键出现的前提下,剩余的属性,不完全依赖于组合主键,也是部分依赖组合主键,比如该表的N条记录中由组合主键中的一条或者几条就可以确定剩余属性的属性,那么就可以说产生部分依赖,而在实际开发中,一般不采用组合主键,而是自己增加一个字段id自增长,作为主键,这样的单属性主键是不会产生部分依赖的!
例如:
讲师P 性别 班级P 教室 代课时间 开始 结束
韩忠康 Male php0331 102 30天 2013-03-31 2013-05-05
韩忠康 Male php0228 106 30天 2013-02-28 2013-03-30
韩顺平 male Php0228 106 15天 2013-03-31 2013-04-20
上面的设计可以用讲师P,班级,两个字段作为组合主键,但是问题来了,那么后面的教室仅仅由班级字段(组合主键中的一条)就可以确定,即所谓教室部分依赖于组合主键,那么就不符合2NF
应该按照下面就行设计:
IDP 讲师 性别 班级 教室 代课时间 开始 结束
1 韩忠康 Male php0331 102 30天 2013-03-31 2013-05-05
2 韩忠康 Male php0228 106 30天 2013-02-28 2013-03-30
可以看到仅仅增加一个主键IDP就不存在部分依赖了,这是实际项目中开发中常用的手段!
三:3NF的理解:不能出现传递依赖:就是主键,非主键1,非主键2三者之间不能出现传递依赖关系,如果出现由主键可以推出非主键1,然后由非主键1可以推出非主键2,那么主键与非主键2就产生了传递依赖关系,这就不满足三范式,通俗来讲,在一个表的,当然以一条记录为单位,主键和非主键之间可以产生父子关系,但是非主键之间是不能出现父子关系的!
例如:
IDP 讲师 性别 班级 教室 代课时间 开始 结束
1 韩忠康 Male php0331 102 30天 2013-03-31 2013-05-05
2 韩忠康 Male php0228 106 30天 2013-02-28 2013-03-30
3 韩顺平 male php0228 106 15天 2013-03-31 2013-04-20
上面的设计不满足3NF:
主键1--推出--->班级php0331,班级php0331-----推出---->教室102,这样给人的感觉,教室不是由主键IDP1直接推出的,好像由班级通过传递推出的;当然还存在
主键IDP---->讲师------>性别
这样的坏处就是会产生数据冗余,解决方案是把中间的代理抽出来作为另外一张表:
应该如下设计:
IDP 讲师 班级 代课时间 开始 结束
1 韩忠康 php0331 30天 2013-03-31 2013-05-05|
2 韩忠康 php0228 30天 2013-02-28 2013-03-30|
3 韩顺平 php0228 15天 2013-03-31 2013-04-20|
--------------------------------------------------------
讲师 性别
韩忠康 male
韩顺平 male
-----------------
班级 教室
php0228 106
php0331 102
-------------
可以看到这样设计只需要用22个字段,而上面那种设计需要用24个字段,这样就节省了2个字段,如果数据是海量的那么节省的数据应该更加多
这样设计,其实为了避免非笛卡尔积数据的重复,当然,笛卡尔积的数据的重复是必须的!
那么数据库的设计可以先按照自己的想法设计一个"大表"出来,然后进行拆分成符合三范式的表,当然一般的规律的实体都单独作为一个表格
比如讲师实体,班级实体,代课关系实体,但是最大的问题是开始不知道哪些是实体,其实除了看得见的,其实说的清的可以描述的关系也可以作为一个实体
,这一点是容易被忽视的,但是随着经验的提升,慢慢会了解!