应用SQL Server 2008数据库原理及应用课件.ppt

第10章数据库系统设计本章学习目标10.1数据库系统设计概述10.1.1数据库和信息系统10.1.2数据库设计的基本步骤图10-1数据库设计流程10.2需求分析10.2.1需求分析的任务10.2.2需求分析的方法10.3概念结构设计10.3.1概念模型的基本概念10.3.2概念模型的表示方法E-R图是描述概念世界、建立概念模型的实用工具，包括3个基本要素：
属性
实体(型)
联系
1.多对多的联系(m︰n)
2.一对多的联系(1︰n)
3.一对一的联系(1︰1)
10.3.3概念结构的特点10.3.4概念结构设计的方法(2)自底向上：这种方法是从具体的对象逐层抽象，最后形成总体概念结构。(3)由内向外：这种方法是从核心的对象着手，然后向四周逐步扩充，直到最终形成总体概念结构。（4)混合策略。该方法采用自顶向下和自底向上相结合的方法，先自顶向下定义全局框架，再以它为骨架集成自底向上方法中设计的各个局部概念结构。
10.3.5概念结构设计的步骤10.4规范化10.4.1关系模式规范化的必要性10.4.2函数依赖部分函数依赖完全函数依赖传递函数依赖10.4.3范式与规范化通常按属性间依赖情况区分关系规范化的程度，定义了不同要求的规范化关系模式，即范式。
目前遵循的主要范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、BC范式(BCNF)、第四范式(4NF)和第五范式(5NF)等。
范式是嵌套的，就是说，属于第二范式的关系必然是属于第一范式的关系，在第五范式中的关系也在第四范式、BC范式、第三范式、第二范式和第一范式中的关系。
第一范式例如：学生选课数据库中将学生、系、课程，选课成绩等所有的信息一起存放。即有关系模式：
StudData(Sno,Sname,Ssex,Ssage,Dno,Dname,Cno,Cname,Credits,Grade)
这个关系的主键(Sno,Cno),，关系StudData就是属于第一范式的，可记作：StudData∈1NF。
第二范式关系StudData属于第一范式。但它不属于第二范式。
原因：存在非主属性Sname、Ssex、Sage、Dno部分函数依赖于主键(Sno,Cno)。所以StudData违反了2NF的定义，它不属于2NF。
消除部分函数依赖的方法就是将关系分解，使其新的关系中非主属性于候选键之间不存在部分函数依赖。前面已经分析过StudData的主键是(Sno,Cno)。所以，Sno,Cno是主属性，其他属性如Sname、Ssex等都是非主属性。根据主键定义，（Sno,Cno）完全函数决定其他非主属性。所以存在如下函数依赖：只要给定学生的学号Sno值，就能知道该学生的姓名、性别等情况，即存在函数依赖分解的方法是投影。具体讲：
(1)用组成候选键的属性集合的每一个非空真子集作为主键构成一个新关系；
(2)对于每个新关系，将完全依赖或传递依赖于此主键的属性放置到此关系中。
下面将StudData关系按上述方法分解：
Grade分解得到三个关系Students、Courses、Enrollmen。
根据2NF的标准衡量，这三个关系中都不存在非主属性部分函数依赖于候选键的情况。所以它们都属于2NF。即Students∈2NF、Courses∈2NF、Enrollmen∈2NF。
结果：冗余问题已得到明显改善，但还有一定的数据冗余，还存在插入异常和删除异常。
属于第二范式的关系同样还可能存在操作异常情况，因此需要进一步规范化。第三范式(3NF)
定义：如果关系R∈2NF，且每一个非主属性都不传递依赖于候选键，则R属于第三范式，记作R∈3NF。
StudData分解后得到的三个关系Students、Courses、Enrollment，它们都属于第二范式了。但Students(Sno,Sname,Ssex,Sage,Dno,Dname)不属于3NF。
原因：SnoDno，DnoDname，存在非主属性Dname传递函数依赖于候选键Sno。根据3NF的定义，Students不属于3NF。
一个关系R若仅属于2NF但不属于3NF，如关系Students，仍然存在数据冗余过多、删除异常和插入异常等问题。
解决的办法仍然是分解，以消除传递依赖。具体方法为：
(1)对于不是候选键的每个决定因子，从原关系中删去依赖于它的所有属性；
(2)对原关系中不是候选键的每个决定因子，新建一个关系，新关系中包含依赖该决定因子的属性；
(3)将该决定因子加入新关系并作为新关系的主键。
按上述方法，来分解Students关系得到：
Students(Sno,Sname,Ssex,Sage,Dno)
Departments(Dno,Dname)最终得到的所有关系：
Students(Sno,Sname