anggi,快乐大本营20120908,朱时茂简历
1、关系数据库规范化理论
为使数据库设计的合理可靠、简单实用，长期以来，形成了关系数据库设计理论，即规范化理论。
完全函数依赖：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。
比如：有一个表，有如下属性：学生id，学生姓名，所修课程id，课程名称，成绩
完全依赖：(学生id，所修课程id)→成绩
成绩既不能单独依赖于学生id，也不能单独依赖于所修课程id，因此成绩完全函数依赖于关键字。
(学生id，所修课程id)→学生姓名
部分依赖：学生id→学生姓名
学生姓名可以依赖于关键字的一个主属性——学生id，因此学生姓名部分函数依赖于(学生id，所修课程id)。
2）平凡函数依赖和非平凡函数依赖
平凡函数依赖：当关系中属性集合y是属性集合x的子集时，存在函数依赖x→y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。
例如：在在关系学生课程表sc(学生号sno,课程号 cno,成绩 grade)中，
(sno, cno) → sno ，(sno, cno) → cno
非平凡函数依赖：当关系中属性集合y不是属性集合x的子集时，存在函数依赖x→y，则称这种函数依赖为非平凡函数依赖。
例如：(sno, cno) → grade
3）传递函数依赖
传递函数依赖：设x,y,z是关系r中互不相同的属性集合，存在x→y(y !→x),y→z，则称z传递函数依赖于x。
例：关系s1(学号，系名，系主任)
学号 → 系名，系名 → 系主任，并且 系名 -\→ 学号，所以 学号 → 系主任 为传递函数依赖
范式是数据库设计中一个重要的过程，通过它可以优化数据库设计，避免一些问题，可以减少数据冗余，可以改进数据库整体组织，可以增强数据的一致性，可以增加数据库设计的灵活性。因此，在确定设计数据库之前，还需对数据库中的表进行范式处理，以确保数据库遵从适当的范式，从而使设计的数据库更加规范。
目前关系数据库有6种范式：第一范式（1nf）、第二范式（2nf）、第三范式（3nf）、第四范式（4nf）、第五范式（5nf）和第六范式（6nf）。满足最低要求的是第一范式（1nf）。在第一范式的基础上满足更多要求的范式称为第二范式（2nf），其余的范式以此类推。一般来说，数据库只需要满足第三范式（3nf）即可。
如果关系模式r的每个关系r的属性都是不可分的数据项，那么就称r是第一范式的模式。第一范式是设计数据库表的最低要求，其最主要的特点是实体的属性不能再分，映射到表中，就是列（或字段）不能再分。
即：一个表中的列是不可再分的（即列的原子性）。
如表1.2，联系范式，对于学号‘1001’学生来说，‘联系方式’列包含电话和邮箱，可以再分，不符合第一范式要求。
如表1.3，列不可再分，符合了第一范式要求。
如果关系模式r满足第一范式，并且r得所有非主属性都完全依赖于r的每一个候选关键属性，称r满足第二范式，简记为2nf。
如表1.3，姓名和选修课有对于关系，但是姓名和教材没有对应关系，选修课程和教材有对对应关系，从而该表不符合第二范式标准。
将表修改后如表1.4和1.5，符合第二范式标准。
如果关系模式r是2nf，且关系模式r（u，f）中的所有非主属性对任何候选键都不存在传递依赖，则成关系r是属于第三范式的模式。
如表1.6满足2nf，但是知道班级后必然能知道该学生 属于哪个系，所以存在传递依赖，不符合3nf规范，所以讲班级和系别属性拆分如表1.7,和1.8，从而符合3nf标准。
| 学号 | 姓名 | 班级 | 系别 |
| 1001 | 张三 | 计算机科学与技术1班 | 计算机系 |
| 1002 | 李四 | 会计1班 | 经管系 |
| 学号 | 姓名 | 班级 |
| 1001 | 张三 | 计算机科学与技术1班 |
| 1002 | 李四 | 会计1班 |
| 班级 | 系别 |
| 计算机科学与技术1班 | 计算机系 |
| 会计1班 | 经管系 |
三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Oracle字符串函数length、upper、lower、initcap、 concat、instr、replace
我要评论
网友评论