数据库及应用程序开发数据库设计.pptVIP

第4章 数据库及应用程序开发 ——数据库设计 西安交通大学 计算机教学实验中心 4.2 数据库设计 只有对数据库进行合理的逻辑设计和有效的物理设计才能开发出完善而高效的信息系统 需求分析 概念设计 逻辑结构设计 物理结构设计 数据库实施阶段 4.2.1需求分析与概念设计 1．需求分析 需求分析就是分析用户的要求 结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用 需求分析的任务： 详细调查要处理的对象 了解原系统工作概况,明确用户的各种需求 确定新系统的功能 考虑今后可能的扩充和改变 信息要求 要从数据库中获得信息的内容与性质 处理要求 要完成什么处理功能，对处理的响应时间有什么要求。 安全性与完整性要求 安全性要求描述不同用户使用和操作数据库的情况 完整性要求描述数据之间的关联以及数据的取值范围 2．概念设计 以DFD和DD提供的信息作为输入，运用信息模型工具对目标进行描述，并以用户能理解的形式表达信息。这种表达独立于具体的DBMS ER方法——实体—联系模型 将现实世界抽象为具有属性的实体及联系。画出一张ER图，就得到了一个对系统信息的初步描述，进而形成数据库的概念模型。 4.2.2逻辑结构设计 ER?关系模型 步骤： 将概念结构转化为一般的关系模型。 将转化来的关系模型向特定DBMS支持下的数据模型转换。 对数据模型进行优化 1．数据库逻辑模型的产生 （1）一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。 （2）一个1:l联系， 可以转换为一个独立的关系模式：各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。 与一端的关系模式合并：在该关系模式的属性中加入另一个关系模式的码和联系本身的属性 。 【例4-43】 将1：1联系的E-R图转换为关系模型。 方案1 职工（职工号，姓名，年龄） 产品（产品号，产品名，价格） 负责（职工号，产品号） 方案2 职工（职工号，姓名，年龄，产品号） 产品（产品号，产品名，价格） 方案3 职工（职工号，姓名，年龄） 产品（产品号，产品名，价格，职工号） 方案3比较合理 (3)一个1：n联系 可以转换为一个独立的关系模式： 与该联系相连的各实体的码以及联系本身的属性均换为关系的属性，而关系的码为n端实体的码 与n端对应的关系模式合并： 联系本身的属性均换为关系的属性，再加1端实体的码 【例4-44】 将含有1：n联系的E-R图转换为关系模型 方案1: 1:n联系形成的关系独立存在。 仓库（仓库号，地点，面积） 产品（产品号，产品名，价格） 仓储（仓库号，产品号，数量） 方案2: 联系形成的关系与n端对象合并 仓库（仓库号，地点，面积） 产品（产品号，产品名，价格，仓库号，数量） 方案2较优 （4）m：n联系 一个m：n联系转换为一个关系模式： 与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 【例4-45】 一个m：n联系转换为一个关系模式 【例4-45】 学生（学号，姓名，年龄，性别）； 课程（课程号，课程名，学时数）； 选修（学号，课程号，成绩）。 (5)三个及以上实体间联系 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 【例4-46】 一个m：n联系转换为一个关系模式 【例4-46】 供应商（供应商号，供应商名，地址） 零件（零件号，零件名，单价） 产品（产品号，产品名，型号） 供应（供应商号，零件号，产品号，数量） (6)同一实体集联系， 按上述1：1，1:n和m：n三种情况分别处理。 【例4-47】 将含有同一实体集的1:n联系的E-R图转换为关系模型 方案1：转换为两个关系模式。 职工（职工号，姓名，年龄） 领导（领导工号，职工号） 方案2:转换为一个关系模式。 职工（职工号，姓名，年龄，领导工号） 【例4-48】 将含有同实体集间m:n联系的E-R图转换为关系模式 零件（零件号，名称，价格） 组装（组装件号，零件号，数量） 2.数据模型的优化 以规范化理论为指导 （1）确定数据依赖。按需求分析，写出各属性之间的数据依赖。 （2）考查是否存在部分函数依赖、传递函数依赖等，确定各关系模式分别属于第几范式。 （3）按照需求分析对数据处理的要求，确定是否需要对它们进行合并或分解。 并不是规范化程度越高的关系就越好 3．设计用户模式 利用视图功能设计更符合局部用户需要的用户外模式。 定义数据库模式主要是从系统的时间效率