01第一章 数据库理论基础.ppt

2010年9月 第*页 Toys（cToyID，vToyName，mToyRate，imPhoto） struct Toys { Char ToyID[6]; Char ToyName[20]; Char ToyRate[8]; Char Photo[30]; Struct_Toys *next; }*Toys 玩具信息A（玩具号，玩具名，玩具价格） 用户A（应用1） 模式 图1-6 三级模式结构实例 玩具信息A（玩具号，玩具名，玩具照片） 内模式 用户B（应用2） 外模式2 外模式1 2010年9月 第*页 五、关系数据库设计的规范化和非规范化 表1-4 带数据示例的表 学号 姓名 …… 学期 数学 英语 2004001 张三 …… 1 40 65 2004001 张三 …… 2 56 48 2004002 李四 …… 1 93 84 2004002 李四 …… 2 85 90 如果修改一个学生的地址,就需要修改和那个学生相关的多行内容，否则将引起数据的不一致。 更新异常—— 插入、修改、删除数据可能导致不一致性。 不一致性—— 数据重复时，更容易引发错误。 无谓地占用额外的磁盘空间。 2010年9月 第*页 五、关系数据库设计的规范化和非规范化 要设计出一个好的数据库，应该遵循下列规则： 每张表中都应有一个标识列。 每张表中只能存放一种实体的数据。 应避免接收带有NULL值的列。 应避免值或列的重复。 2010年9月 第*页 （一） 规范化设计 规范化将导致满足某些特定规则并代表某些范式的表的形成。 范式用于确保数据库中不存在各种类型的异常和不一致。 表结构总是属于某个特定的范式。 各范式之间的关系 非规范化关系 1NF 2NF 3NF BCNF …… 2010年9月 第*页 1．第一范式（1NF） 当表中的每个单元含且仅含一个值时，这个表叫做第一范式（1 NF）。 Ecode Dept ProjCode Hours E101 Systems P27 P51 P20 90 101 60 E305 Sales P27 P22 109 98 E508 Admin P51 P27 NULL 72 Ecode Dept ProjCode Hours E101 Systems P27 90 E101 Systems P51 101 E101 Systems P20 60 E305 Sales P27 109 E305 Sales P22 98 E508 Admin P51 NULL 2010年9月 第*页 （一） 规范化设计 函数依赖 给定一个关系（你可以称其为表，也可以称其为关系）R，如果R中A的每个值都与B的某个确定值相对应，则属性A函数依赖于B。换句话说，当且仅当对于B的每个值都能够在A中找到一个确定的值时，属性A函数依赖于B。属性 B称为决定因子。 Code Name City E1 Mac Delhi E2 Sandra CA E3 Henry Paris 定义：设R（U）是属性集U上的关系模式。X，Y是U的子集。若对于R（U）的任意一个可能的关系实例r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖于X，记作X--》Y 例：姓名?年龄 这个函数依赖只有在没有同名人的条件下成立。 2010年9月 第*页 2．第二范式（2NF） 当一个表是1 NF 且一行中的每个非主属性都依赖于整个关键字（不仅仅是关键字的一部分）时，该表就可以称作第二范式。 定义：若关系模式R?1NF，并且每一个非主属性都完全依赖于R的码，则为2NF。 定义：若Ｙ依赖于X，并且对于Ｘ的任何一个真子集X’，都有Y不依赖于X’,则称Y完全依赖于Ｘ，否则称Ｙ部分依赖于Ｘ。 例：成绩表(学号，课程号，成绩) 住所(学号，系别，住址) 2010年9月 第*页 2．第二范式（2NF） Ecode ProjCode Dept Hours E101 P27 Systems 90 E305 P27 Finance 10 E508 P51 Admin NULL E101 P51 Systems 101 E101 P20 Systems 60 E508 P27 Admin 72 考查下表，主键是(ecode projcode) Dept依赖于Ecode，所以dept不完全依赖于码(Ecode projcode)。不属于第二范式。 2010年9月 第*页 2．第二范式（2NF） EmployeeDept Project ECode Dept ECode ProjCode Hours E101 Systems E101 P27 90 E30 Sales E101 P51 101 E50 A