(第2章 数据库设计.ppt

需求分析阶段 概念结构设计阶段 逻辑结构设计阶段 物理结构设计阶段 实施阶段 使用与维护阶段 详细调查现实世界要处理的对象（组织、部门、企业等） 充分了解原系统（手工系统或计算机系统） 明确用户的各种需求 确定新系统的功能 充分考虑今后可能的扩充和改变 调查的重点是“数据”和“处理”，获得用户对数据库要求 ? (1)信息要求 ? (2)处理要求 ? (3)安全性与完整性要求 (1)确定用户最终需求 用户缺少计算机知识 设计人员缺少用户的专业知识 (2)解决方法 ? 设计人员必须不断深入地与用户进行交流 (1)调查需求 (2)达成共识 (3)分析表达需求 需求分析阶段的具体做法(见课本P18) 常用调查方法:跟班作业、开调查会、请专人介绍、询问、设计调 查表请用户填写、查阅记录 2、函数依赖 目的：分析关系属性之间的依赖情况 函数依赖 平凡函数依赖与非平凡函数依赖 平凡函数依赖与非平凡函数依赖 函数依赖 完全函数依赖与部分函数依赖 完全函数依赖与部分函数依赖 传递函数依赖 码 码 关系范式 将关系模式分解到第三范式 关系分解的正确性 第一范式(1NF) 第一范式(1NF) 第一范式(1NF) 第二范式(2NF) 第二范式(2NF) 1NF改造为2NF的方法：模式分解 第二范式的缺点 第三范式(3NF) 第三范式(3NF) 分解到3NF的关系模式 2.6 数据库实施(P41-P42) 运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 2.7 数据库使用与维护(P42) 数据库应用系统经过试运行后即可投入正式 运行。在数据库系统运行过程中必须不断地对其 进行评价、调整与修改。 2.4.1 关系模型(P26-P32) 关系模型的完整性约束(P30-P31) (2)实体完整性(P30) 概念：若属性A是基本关系R的主属性，则A不能取空值Null且不能有相同值。 例如：学生(学号,姓名,性别,年龄) 学号是主属性，则学号不能为空值且不能有相同值。 2.4.1 关系模型(P26-P32) 关系模型的完整性约束(P30-P31) (3)参照完整性(P31) 概念：关系R中的外码F必须是另一个关系S的主码K有效值，或者是NULL。 例如：学生(学号，姓名，性别，系编号，年龄） 系(系编号，系名，系主任） 对于学生关系，系编号是外码，学生关系中的系编号 取值，要参照系关系中系编号的值。 2.4.1 关系模型(P26-P32) 关系模型的主要特点 (1)关系中每一分量不可再分，是最基本的数据单位。 (2)每一列的分量是同属性的，列数根据需要而设，且各列的顺序是任意的。 (3)每一行由一个实体的诸多属性构成，且各行的顺序可以是任意的。 (4)一个关系是一张二维表，不允许有相同的属性名，也不允许有相同的元组。 2.4.2 关系规范化(P32-P37) 1、数据库设计中的问题 2、函数依赖 3、关系规范化 2.4.2 关系规范化(P32-P37) 1、数据库设计中的问题 (1)数据冗余 (2)更新异常 (3)插入异常 (4)删除异常 函数依赖 (非平凡函数依赖、平凡函数依赖) 完全函数依赖 (部分函数依赖) 传递函数依赖 2.4.2 关系规范化(P32-P37) 关系中一个或一组属性的值可以决定其它属性的值 。函数依赖正象一个函数y=f(x)一样，x的值给定后，y的值也就唯一地确定了。 记作：X-Y 2.4.2 关系规范化(P32-P37) 例题：有关系职工(职工号，基本工资，奖金），一个职工号唯一确定一个基本工资数额或一个奖金额，即一个人不能拿两种工资或奖金，但几个人的工资可能相同。设属性A是职工号,属性B是基本工资，属性C是奖金。 可以看出，每个A的值对应一个B的值和一个C的值。因此属性B和C都函数依赖于属性A。用符号表示:A→B,A→C 2.4.2 关系规范化(P32-P37) 在关系模式R(U)中，对于U的子集X和Y， 1)若X→Y，但Y ? X，则称X→Y是非平凡的函数依赖 2)若X→Y，但Y ? X, 则称X→Y是平凡的函数依赖 2.4.2 关系规范化(P32-P37) 例题：在关系SC(Sno, Cno, Grade)中， (1)非平凡函数依赖 (Sno, Cno)→ Grade (2)平凡函数依赖： (Sno, Cno) → Sno (Sno, Cno) → Cno 2.4.2 关系规范化(P32-P37) 根据函数依赖的不同性质 完全函数依赖 部分函数依赖 传递函数依赖 2