4.2数据库设计.ppt

4.2 数据库设计 需求分析 概念设计 逻辑结构设计 物理结构设计 数据库实施阶段 4.2.1需求分析与概念设计 1．需求分析 详细调查要处理的对象 了解原系统工作概况 确定新系统的功能 考虑今后可能的扩充和改变 信息要求 要从数据库中获得信息的内容与性质 处理要求 要完成什么处理功能，对处理的响应时间有什么要求。 安全性与完整性要求 2．概念设计 将现实世界抽象为具有属性的实体及及联系。画出一张ER图，就得到了一个对系统信息的初步描述，进而形成数据库的概念模型。 4.2.2逻辑结构设计 将概念结构转化为一般的关系模型。 ·将转化来的关系模型向特定DBMS支持下的数据模型转换。 ·对数据模型进行优化 1．数据库逻辑模型的产生 （1）一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。 （2）一个1:l联系 一个独立的关系模式：各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。 与一端的关系模式合并：在该关系模式的属性中加入另一个关系模式的码和联系本身的属性 。 方案1 职工（职工号，姓名，年龄） 产品（产品号，产品名，价格） 负责（职工号，产品号） 方案2 职工（职工号，姓名，年龄，产品号） 产品（产品号，产品名，价格） 方案3 职工（职工号，姓名，年龄） 产品（产品号，产品名，价格，职工号） 方案3比较合理 方案1: 1:n联系形成的关系独立存在。 仓库（仓库号，地点，面积） 产品（产品号，产品名，价格） 仓储（仓库号，产品号，数量） 方案2: 联系形成的关系与n端对象合并 仓库（仓库号，地点，面积） 产品（产品号，产品名，价格，仓库号，数量） 方案2较优 (3)一个1：n联系 一个独立的关系模式： 与该联系相连的各实体的码以及联系本身的属性均换为关系的属性，而关系的码为n端实体的码 与n端对应的关系模式合并： 联系本身的属性均换为关系的属性，再加1端实体的码 学生（学号，姓名，年龄，性别）； 课程（课程号，课程名，学时数）； 选修（学号，课程号，成绩）。 （4）m：n联系 一个m：n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 供应商（供应商号，供应商名，地址） 零件（零件号，零件名，单价） 产品（产品号，产品名，型号） 供应（供应商号，零件号，产品号，数量） (5)三个及以上实体间联系 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 方案1：转换为两个关系模式。 职工（职工号，姓名，年龄） 领导（领导工号，职工号） 方案2:转换为一个关系模式。 职工（职工号，姓名，年龄，领导工号） (6)同一实体集联系， 按上述1：1，1:n和m：n三种情况分别处理。 零件（零件号，名称，价格） 组装（组装件号，零件号，数量） 2.数据模型的优化 以规范化理论为指导 （1）确定数据依赖。按需求分析，写出各属性之间的数据依赖。 （2）考查是否存在部分函数依赖、传递函数依赖等，确定各关系模式分别属于第几范式。 （3）按照需求分析对数据处理的要求，确定是否需要对它们进行合并或分解。 3．设计用户模式 利用视图功能设计更符合局部用户需要的用户外模式。 （1）使用更符合用户习惯的别名 （2）针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 4.2.3数据库物理设计及实施 物理设备上的存储结构与存取方法称为数据库的物理结构 1．确定数据的存储结构 综合考虑存取时间、存储空间利用率和维护代价3方面的因素。 2．设计数据的存取路径 在关系数据库中，选择存取路径主要是指确定如何建立索引。 （1）聚簇索引 聚簇键相同的元组自然地被放在同一个物理页中，如果元组过多，一个物理页放不下，则被链接到多个物理页中 。 （2）非聚簇索引 索引页上的顺序与物理数据页上的顺序一般不一致。 建立索引原则 一个（组）属性经常在操作条件中出现。 一个（组）属性经常作为聚集函数的参数。 一个（组）属性经常在连接操作的连接条件中出现。 建立聚簇索引原则 检索数据时，常以某个（组）属性作为排序、分组条件。 检索数据时，常以某个（组）属性作为检索限制条件，并返回大量数据。 表中某个（组）的值重复性较大。 3．确定数据的存放位置 数据库数据备份、日志文件备份等，可以考虑存放在磁带上。 可以考虑将表和索引分别放在不同的磁盘上。在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。 4．确定系统