DB07数据库教学名师优质课赛课一等奖市公开课获奖课件

第7章数据库设计教学要求：掌握概念结构、逻辑结构、物理结构概念及数据库从分析到设计数据库过程；了解数据库设计特点，数据库物理设计内容和评价，数据库实施和维护。重点与难点：概念结构中导出综合E-R图及逻辑结构设计规范化处理过程；数据模型优化，设计出符合详细领域要求数据库及其应用系统

第1页数据库设计概述需求分析概念结构设计逻辑结构设计数据库物理设计数据库实施和维护第7章数据库设计第2页7.1数据库设计概述数据库是信息系统关键和基础,只有对数据库进行合理逻辑设计和有效物理设计才能开发出完善而高效信息系统信息系统种类（OAS、MIS、DSS等）第3页7.1数据库设计概述数据库设计数据库设计是指对于一个给定应用环境，结构（设计）优化数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存放和管理数据，满足各种用户应用需求，包含信息管理要求和数据操作要求。目标：为用户和各种应用系统提供一个信息基础设施和高效率运行环境第4页7.1.1数据库设计特点数据库建设基本规律三分技术，七分管理，十二分基础数据管理数据库建设项目管理企业（即应用部门）业务管理基础数据搜集、入库更新新数据结构（数据）设计和行为（处理）设计相结合将数据库结构设计和数据处理设计亲密结合第5页现实世界概念模型设计子模式设计物理数据库设计逻辑数据库设计建立数据库数据分析功效分析功效模型功效说明事务设计程序说明应用程序设计程序编码调试图7.1结构和行为分离设计

7.1.1数据库设计特点第6页7.1.2数据库设计方法对于从事数据库设计专业人员来讲，应该具备多方面技术和知识。主要有:数据库基本知识；计算机基础知识程序设计方法和技巧；软件工程原理和方法；数据库设计技术应用领域知识。第7页手工与经验相结合方法设计质量与设计人员经验和水平有直接关系数据库运行一段时间后经常不一样程度地发觉各种问题，增加了维护代价规范设计法基本思想：过程迭代和逐步求精7.1.2数据库设计方法第8页新奥尔良（NewOrleans）方法将数据库设计分为若干阶段和步骤基于E-R模型数据库设计方法概念设计阶段广泛采取3NF（第三范式）设计方法逻辑阶段可采取有效方法ODL（ObjectDefinitionLanguage）方法面向对象数据库设计方法7.1.2数据库设计方法第9页计算机辅助设计ORACLEDesignerSYBASEPowerDesigner7.1.2数据库设计方法第10页7.1.3数据库设计基本步骤数据库设计分6个阶段需求分析概念结构设计逻辑结构设计物理结构设计数据库实施数据库运行和维护需求分析和概念设计独立于任何数据库管理系统逻辑设计和物理设计与选取DBMS亲密相关第11页一、数据库设计准备工作：选定参加设计人1.系统分析人员、数据库设计人员自始至终参加数据库设计2.用户和数据库管理员主要参加需求分析和数据库运行维护3.应用开发人员（程序员和操作员）在系统实施阶段参加进来，负责编制程序和准备软硬件环境7.1.3数据库设计基本步骤第12页二、数据库设计过程(六个阶段)⒈需求分析阶段准确了解与分析用户需求（包含数据与处理）最困难、最花费时间一步⒉概念结构设计阶段整个数据库设计关键经过对用户需求进行综合、归纳与抽象，形成一个独立于详细DBMS概念模型7.1.3数据库设计基本步骤第13页⒊逻辑结构设计阶段将概念结构转换为某个DBMS所支持数据模型对其进行优化⒋数据库物理设计阶段为逻辑数据模型选取一个最适合应用环境物理结构（包含存放结构和存取方法）7.1.3数据库设计基本步骤第14页7.1.3数据库设计基本步骤⒌数据库实施阶段利用DBMS提供数据库语言（如SQL）及宿主语言，依据逻辑设计和物理设计结果建立数据库编制与调试应用程序组织数据入库进行试运行第15页⒍数据库运行和维护阶段数据库应用系统经过试运行后即可投入正式运行在数据库系统运行过程中必须不停地对其进行评价、调整与修改7.1.3数据库设计基本步骤第16页7.1.3数据库设计基本步骤

设计一个完善数据库应用系统往往是上述六个阶段不停重复（P202图7.2）把数据库设计和对数据库中数据处理设计紧密结合起来将这两个方面需求分析、抽象、设计、实现在各个阶段同时进行，相互参考，相互补充，以完善两方面设计第17页7.1.3数据库设计基本步骤第18页7.1.3数据库设计基本步骤第19页7.1.4数据库设计过程中各级模式数据库设计不一样阶段形成数据库各级模式图7.4数据库各级模式

第20页7.2需求分析需求分析任务需求分析方法数据字典第21页7.2.1需求分析任务需求分析任务需求分析重点需求分析难点第22页详细调查现实世界要处理对象（组织、部门、企业等）充分了解原系统（手工系统或计算机系统）明确用户各种需求确定新系统功效充分考虑今后可能扩充和改变7.2.1需求分析任务任务：第23页调查重点是“数据”和“处理”，取得用户对数据库要求信息要求处理要求安全性与完整性要求重点：7.2.1需求分析任务第24页确定用户最终需求用户缺乏计算机知识设计人员缺乏用户专业知识处理方法设计人员必须不停深入地与用户进行交流7.2.1需求分析任务难点：第25页7.2.2需求分析方法调查需求达成共识分析表示需求第26页调查用户需求详细步骤⑴调查组织机构情况⑵调查各部门业务活动情况。⑶在熟悉业务活动基础上，帮助用户明确对新系统各种要求。⑷确定新系统边界7.2.2需求分析方法第27页惯用调查方法(1)跟班作业(2)开调查会(3)请专员介绍(4)问询(5)设计调查表请用户填写(6)查阅统计7.2.2需求分析方法第28页7.2.2需求分析方法分析和表示用户需求方法：第29页结构化分析方法（StructuredAnalysis，简称SA方法） 从最上层系统组织机构入手自顶向下、逐层分解分析系统7.2.2需求分析方法第30页1.首先把任何一个系统都抽象为：数据流数据流数据存放信息要求数据起源处理数据输出处理要求7.2.2需求分析方法第31页2.分解处理功效和数据

(1)分解处理功效将处理功效详细内容分解为若干子功效

(2)分解数据处理功效逐步分解同时，逐层分解所用数据，形成若干层次数据流图

(3)表示方法处理逻辑：用判定表或判定树来描述数据：用数据字典来描述3.将分析结果再次提交给用户，征得用户认可7.2.2需求分析方法第32页需求分析过程图7.6需求分析过程7.2.2需求分析方法第33页7.2.3数据字典数据字典用途进行详细数据搜集和数据分析所取得主要结果数据字典内容数据项数据结构数据流数据存放处理过程第34页⒈数据项

数据项是不可再分数据单位对数据项描述

数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其它数据项逻辑关系，数据项之间联络｝7.2.3数据字典第35页⒉数据结构数据结构反应了数据之间组合关系。一个数据结构能够由若干个数据项组成，也能够由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构描述数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝7.2.3数据字典第36页⒊数据流数据流是数据结构在系统内传输路径。对数据流描述

数据流描述＝｛数据流名，说明，数据流起源，数据流去向，组成:｛数据结构｝，平均流量，高峰期流量｝7.2.3数据字典第37页⒋数据存放数据存放是数据结构停留或保留地方，也是数据流起源和去向之一。对数据存放描述

数据存放描述＝｛数据存放名，说明，编号， 输入数据流，输出数据流，组成:｛数据结构｝，数据量，存取频度，存取方式｝7.2.3数据字典第38页7.2.3数据字典⒌处理过程详细处理逻辑普通用判定表或判定树来描述处理过程说明性信息描述

处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝，处理:｛简明说明｝｝第39页数据字典举例例：学生学籍管理子系统数据字典。数据项，以“学号”为例：数据项：学号含义说明：唯一标识每个学生别名：学生编号类型：字符型长度：8

取值范围：00000000至99999999取值含义：前两位标别该学生所在年级，后六位按次序编号与其它数据项逻辑关系：7.2.3数据字典第40页数据结构，以“学生”为例“学生”是该系统中一个关键数据结构：数据结构：学生含义说明：是学籍管理子系统主体数据结构，定义了一个学生相关信息组成：学号，姓名，性别，年纪，所在系，年级

7.2.3数据字典第41页数据流，“体检结果”可以下描述：数据流：体检结果说明：学生参加体格检验最终止果数据流起源：体检数据流去向：同意组成：……平均流量：……高峰期流量：……7.2.3数据字典第42页数据存放，“学生记录表”可以下描述：数据存放：学生记录表说明：统计学生基本情况流入数据流：……

流出数据流：……

组成：……

数据量：每年3000张存取方式：随机存取

7.2.3数据字典第43页处理过程“分配宿舍”可以下描述：处理过程：分配宿舍说明：为全部新生分配学生宿舍输入：学生，宿舍输出：宿舍安排处理：在新生报到后，为全部新生分配学生宿舍。要求同一间宿舍只能安排同一性别学生，同一个学生只能安排在一个宿舍中。每个学生居住面积大于3平方米。安排新生宿舍其处理时间应不超出15分钟。7.2.3数据字典第44页数据字典是关于数据库中数据描述，是元数据，而不是数据本身数据字典在需求分析阶段建立，在数据库设计过程中不停修改、充实、完善7.2.3数据字典第45页设计人员应充分考虑到可能扩充和改变，使设计易于更改，系统易于扩充必须强调用户参加需求分析小结第46页7.3概念结构设计概念结构概念结构设计方法与步骤数据抽象与局部视图设计视图集成第47页7.3.1概念结构什么是概念结构设计将需求分析得到用户需求抽象为信息结构即概念模型过程就是概念结构设计概念结构是各种数据模型共同基础，它比数据模型更独立于机器、更抽象，从而愈加稳定概念结构设计是整个数据库设计关键第48页现实世界机器世界信息世界需求分析概念结构设计7.3.1概念结构第49页概念结构设计特点

(1)能真实、充分地反应现实世界

(2)易于了解

(3)易于更改

(4)易于向关系、网状、层次等各种数据模型转换7.3.1概念结构描述概念模型工具E-R模型第50页7.3.2概念结构设计方法与步骤设计概念结构四类方法自顶向下首先定义全局概念结构框架，然后逐步细化第51页自底向上首先定义各局部应用概念结构，然后将它们集成起来，得到全局概念结构7.3.2概念结构设计方法与步骤第52页逐步扩张首先定义最主要关键概念结构，然后向外扩充，以滚雪球方式逐步生成其它概念结构，直至总体概念结构7.3.2概念结构设计方法与步骤第53页混合策略将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构框架，以它为骨架集成由自底向上策略中设计各局部概念结构。7.3.2概念结构设计方法与步骤第54页惯用策略自顶向下地进行需求分析自底向上地设计概念结构7.3.2概念结构设计方法与步骤第55页自底向上设计概念结构步骤第1步：抽象数据并设计局部视图第2步：集成局部视图，得到全局概念结构7.3.2概念结构设计方法与步骤第56页7.3.3数据抽象与局部视图设计抽象是对实际人、物、事和概念中抽取所关心共同特征，忽略非本质细节，并把这些特征用各种概念准确地加以描述。概念结构是对现实世界一个抽象数据抽象第57页三种惯用抽象1.分类（Classification）定义某一类概念作为现实世界中一组对象类型抽象了对象值和型之间“ismemberof”语义7.3.3数据抽象与局部视图设计第58页2.聚集（Aggregation）定义某一类型组成成份抽象了对象内部类型和成份之间“ispartof”语义聚集

7.3.3数据抽象与局部视图设计第59页复杂聚集，某一类型成份仍是一个聚集7.3.3数据抽象与局部视图设计更复杂聚集

第60页3.概括（Generalization）定义类型之间一个子集联络抽象了类型之间“issubsetof”语义继承性

7.3.3数据抽象与局部视图设计第61页概括7.3.3数据抽象与局部视图设计第62页局部视图设计7.3.3数据抽象与局部视图设计设计分E-R图步骤:⒈选择局部应用⒉逐一设计分E-R图第63页在多层数据流图中选择一个适当层次数据流图，作为设计分E-R图出发点通常以中层数据流图作为设计分E-R图依据7.3.3数据抽象与局部视图设计⒈选择局部应用第64页7.3.3数据抽象与局部视图设计设计分E-R图出发点

第65页⒉逐一设计分E-R图7.3.3数据抽象与局部视图设计任务将各局部应用包括数据分别从数据字典中抽取出来参考数据流图，标定各局部应用中实体、实体属性、标识实体码确定实体之间联络及其类型（1:1，1:n，m:n）第66页7.3.3数据抽象与局部视图设计两条准则：（1）属性不能再含有需要描述性质。即属性必须是不可分数据项，不能再由另一些属性组成（2）属性不能与其它实体含有联络。联络只发生在实体之间第67页职称作为一个实体7.3.3数据抽象与局部视图设计第68页病房作为一个实体7.3.3数据抽象与局部视图设计第69页仓库作为一个实体7.3.3数据抽象与局部视图设计第70页［实例］销售管理子系统分E-R图设计销售管理子系统主要功效：处理用户和销售员送来订单工厂是依据订货安排生产交出货物同时开出发票收到用户付款后，依据发票存根和信贷情况进行应收款处理7.3.3数据抽象与局部视图设计第71页下列图是第一层数据流图，虚线部分划出了系统边界

图7.18销售管理子系统第一层数据流图

7.3.3数据抽象与局部视图设计第72页上图中把系统功效又分为4个子系统，下面四个图是第二层数据流图图7.19接收订单

7.3.3数据抽象与局部视图设计第73页图7.20处理订单

7.3.3数据抽象与局部视图设计第74页图7.21开发票

7.3.3数据抽象与局部视图设计第75页7.3.3数据抽象与局部视图设计图7.22支付过账

第76页分E-R图框架

7.3.3数据抽象与局部视图设计第77页参考第二层数据流图和数据字典，遵照两个准则，进行以下调整：(1)订单与订单细节是1∶n联络(2)原订单和产品联络实际上是订单细节和产品联络。(3)图7.21中“发票主清单”是一个数据存放，无须作为实体加入分E-R图(4)工厂对大宗订货给予优惠7.3.3数据抽象与局部视图设计第78页得到分E-R图以下列图所表示销售管理子系统分E-R图7.3.3数据抽象与局部视图设计第79页对每个实体定义属性以下：用户：{用户号，用户名，地址，电话，信贷情况，账目余额}订单：{订单号，用户号，订货项数，订货日期，交货日期，工种号，生产地点}订单细则：{订单号，细则号，零件号，订货数，金额}应收账款：{用户号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额}产品描述：{产品号，产品名，单价，重量}折扣规则：{产品号，订货量，折扣}7.3.3数据抽象与局部视图设计第80页7.3.4视图集成各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体数据概念结构即总E-R图。第81页视图集成两种方式7.3.4视图集成多个分E-R图一次集成一次集成多个分E-R图通惯用于局部视图比较简单时第82页逐步集成用累加方式一次集成两个分E-R图

7.3.4视图集成第83页集成局部E-R图步骤1.合并2.修改与重构7.3.4视图集成第84页7.3.4视图集成视图集成

第85页一、合并分E-R图，生成初步E-R图7.3.4视图集成

各分E-R图存在冲突各个分E-R图之间必定会存在许多不一致地方合并分E-R图主要工作与关键合理消除各分E-R图冲突第86页7.3.4视图集成冲突种类属性冲突命名冲突结构冲突第87页⒈属性冲突7.3.4视图集成两类属性冲突属性域冲突属性值类型取值范围取值集合不一样属性取值单位冲突第88页⒉命名冲突7.3.4视图集成两类命名冲突同名异义：不一样意义对象在不一样局部应用中含有相同名字异名同义（一义多名）：同一意义对象在不一样局部应用中含有不一样名字第89页⒊结构冲突三类结构冲突同一对象在不一样应用中含有不一样抽象同一实体在不一样分E-R图中所包含属性个数和属性排列次序不完全相同实体之间联络在不一样局部视图中展现不一样类型7.3.4视图集成第90页7.3.4视图集成第91页7.3.4视图集成二、消除无须要冗余，设计基本E-R图合并初步E-R图分E-R图可能存在冗余数据和冗余实体间联络基本E-R图消除无须要冗余第92页冗余消除冗余方法7.3.4视图集成第93页7.3.4视图集成1．冗余冗余数据是指可由基本数据导出数据,冗余联络是指可由其它联络导出联络冗余数据和冗余联络轻易破坏数据库完整性，给数据库维护增加困难消除无须要冗余后初步E-R图称为基本E-R图

第94页2.消除冗余方法7.3.4视图集成分析方法以数据字典和数据流图为依据依据数据字典中关于数据项之间逻辑关系第95页7.3.4视图集成消除冗余

Q3=Ql×Q2,Q4=∑Q5第96页效率VS冗余信息需要依据用户整体需求来确定若人为地保留了一些冗余数据，则应把数据字典中数据关联说明作为完整性约束条件Q4=∑Q5当Q5修改后就应该触发完整性检验，对Q4进行修改7.3.4视图集成第97页7.3.4视图集成规范化理论函数依赖概念提供了消除冗余联络形式化工具第98页方法1.确定分E-R图实体之间数据依赖，并用实体码之间函数依赖表示。劳感人事管理分E-R图

7.3.4视图集成第99页上图中，部门和职员之间一对多联络可表示为：职员号→部门号职员和产品之间多对多联络可表示为：（职员号，产品号）→工作天数得到函数依赖集FL

7.3.4视图集成第100页2.求FL最小覆盖GL

，差集为D=FL-GL。逐一考查D中函数依赖，确定是否是冗余联络，若是，就把它去掉。(1)冗余联络一定在D中，而D中联络不一定是冗余；(2)当实体之间存在各种联络时要将实体之间联络在形式上加以区分。7.3.4视图集成第101页消除冗余，设计生成基本E-R图实例7.3.4视图集成

［实例］某工厂管理信息系统视图集成。

书中图1.14(c)、图7.24、图7.29分别为该厂物资、销售和劳感人事管理分E-R图图7.30为该系统基本E-R图第102页图1.14(c)工厂物资管理E-R图该厂物资管理分E-R图7.3.4视图集成第103页图7.24销售管理子系统分E-R图该厂销售管理分E-R图7.3.4视图集成第104页图7.29劳感人事管理分E-R图该厂劳感人事管理分E-R图7.3.4视图集成第105页系统基本E-R图(图7.30)某工厂管理信息系统基本E-R图7.3.4视图集成第106页集成过程，处理了以下问题：异名同义，项目和产品含义相同库存管理中职员与仓库工作关系已包含在劳感人事管理部门与职员之间联络之中，所以能够取消职员之间领导与被领导关系可由部门与职员（经理）之间领导关系、部门与职员之间隶属关系二者导出，所以也能够取消7.3.4视图集成第107页视图集成后形成一个整体数据库概念结构，对该整体概念结构还必须进行深入验证，确保它能够满足以下条件：整体概念结构内部必须含有一致性，不存在相互矛盾表示整体概念结构能准确地反应原来每个视图结构，包含属性、实体及实体间联络整体概念结构能满足需要分析阶段所确定全部要求验证整体概念结构7.3.4视图集成第108页整体概念结构最终还应该提交给用户，征求用户和相关人员意见，进行评审、修改和优化，然后把它确定下来，作为数据库概念结构，作为深入设计数据库依据。7.3.4视图集成第109页概念结构设计小结概念结构设计步骤抽象数据并设计局部视图集成局部视图，得到全局概念结构验证整体概念结构第110页数据抽象分类聚集概括概念结构设计小结第111页设计局部视图1.选择局部应用2.逐一设计分E-R图标定局部应用中实体、属性、码，实体间联络用E-R图描述出来概念结构设计小结第112页集成局部视图1.合并分E-R图，生成初步E-R图消除冲突属性冲突命名冲突结构冲突2.修改与重构消除无须要冗余，设计生成基本E-R图分析方法规范化理论概念结构设计小结第113页7.4逻辑结构设计逻辑结构设计任务把概念结构设计阶段设计好基本E-R图转换为与选取DBMS产品所支持数据模型相符合逻辑结构逻辑结构设计步骤将概念结构转化为普通关系、网状、层次模型将转换来关系、网状、层次模型向特定DBMS支持下数据模型转换对数据模型进行优化第114页

逻辑结构设计时3个步骤

7.4逻辑结构设计第115页7.4.1E-R图向关系模型转换E-R图向关系模型转换要处理问题怎样将实体型和实体间联络转换为关系模式怎样确定这些关系模式属性和码转换内容将E-R图转换为关系模型：将实体、实体属性和实体之间联络转换为关系模式。第116页7.4.1E-R图向关系模型转换关系模型特点之一是概念单一性。不论是实体型还是实体间联络都用关系来表示。关系这个特点使得转换工作比较直接。详细转换标准以下：一个实体型转换为一个关系模式，实体属性就是关系属性，实体码就是关系码。第117页实体型间联络有以下不一样情况：(1)一个1:1联络能够转换为一个独立关系模式，也能够与任意一端对应关系模式合并。转换为一个独立关系模式与某一端实体对应关系模式合并(2)一个1:n联络能够转换为一个独立关系模式，也能够与n端对应关系模式合并。转换为一个独立关系模式与n端对应关系模式合并7.4.1E-R图向关系模型转换第118页学校（校名，地址，电话，校长名，任职年月）校长（姓名，性别，年纪，职称）7.4.1E-R图向关系模型转换第119页系（系号，系名，电话）教师（工号，姓名，性别，年纪，系号，聘期）7.4.1E-R图向关系模型转换第120页(3)一个m:n联络转换为一个关系模式。 例，“选修”联络是一个m:n联络，能够将它转换为以下关系模式，其中学号与课程号为关系组合码：选修（学号，课程号，成绩）7.4.1E-R图向关系模型转换第121页学生（学号，姓名，年纪，性别）选课（学号，课程号，成绩）课程（课程号，课程名，教师名）7.4.1E-R图向关系模型转换第122页(4)三个或三个以上实体间一个多元联络转换为一个关系模式。与该联络相连各实体码以及联络本身属性均转换为关系属性，各实体码组成关系码或关系码一部分。

7.4.1E-R图向关系模型转换第123页(5)含有相同码关系模式可合并目标：降低系统中关系个数合并方法：将其中一个关系模式全部属性加入到另一个关系模式中，然后去掉其中同义属性（可能同名也可能不一样名），并适当调整属性次序7.4.1E-R图向关系模型转换第124页注意：从理论上讲，1:1联络能够与任意一端对应关系模式合并但在一些情况下，与不一样关系模式合并效率会大不一样。所以终究应该与哪端关系模式合并需要依应用详细情况而定。因为连接操作是最费时操作，所以普通应以尽可能降低连接操作为目标。比如，假如经常要查询某个班级班主任姓名，则将管理联络与教师关系合并更加好些7.4.1E-R图向关系模型转换第125页[例]把图7.30中虚线上部E-R图转换为关系模型部门实体对应关系模式部门（部门号，部门名，经理职员号，…）此关系模式已包含了联络“领导”所对应关系模式经理职员号是关系候选码职员实体对应关系模式职员（职员号、部门号，职员名，职务，…）该关系模式已包含了联络“属于”所对应关系模式7.4.1E-R图向关系模型转换第126页7.4.1E-R图向关系模型转换产品实体对应关系模式产品（产品号，产品名，产品组长职员号，…）供给商实体对应关系模式供给商（供给商号，姓名，…）零件实体对应关系模式零件（零件号，零件名，…）联络“参加”所对应关系模式职员工作（职员号，产品号，工作天数，…）联络“供给”所对应关系模式供给（产品号，供给商号，零件号，供给量）第127页7.4.2数据模型优化得到初步数据模型后，还应该适当地修改、调整数据模型结构，以深入提升数据库应用系统性能，这就是数据模型优化关系数据模型优化通常以规范化理论为指导第128页7.4.2数据模型优化优化数据模型方法1.确定数据依赖按需求分析阶段所得到语义，分别写出每个关系模式内部各属性之间数据依赖以及不一样关系模式属性之间数据依赖2.消除冗余联络对于各个关系模式之间数据依赖进行极小化处理，消除冗余联络。第129页3.确定所属范式7.4.2数据模型优化按照数据依赖理论对关系模式逐一进行分析考查是否存在部分函数依赖、传递函数依赖、多值依赖等确定各关系模式分别属于第几范式

第130页7.4.2数据模型优化4.按照需求分析阶段得到各种应用对数据处理要求，分析对于这么应用环境这些模式是否适当，确定是否要对它们进行合并或分解。注意：并不是规范化程度越高关系就越优，一般说来，第三范式就足够了第131页5.按照需求分析阶段得到各种应用对数据处理要求，对关系模式进行必要分解，以提升数据操作效率和存放空间利用率惯用分解方法水平分解垂直分解7.4.2数据模型优化第132页水平分解什么是水平分解把(基本)关系元组分为若干子集合，定义每个子集合为一个子关系，以提升系统效率水平分解适用范围满足“80/20标准”应用并发事务经常存取不相交数据7.4.2数据模型优化第133页垂直分解什么是垂直分解把关系模式R属性分解为若干子集合，形成若干子关系模式垂直分解适用范围取决于分解后R上全部事务总效率是否得到了提升7.4.2数据模型优化第134页7.4.3设计用户子模式定义用户外模式时应该重视问题包含三个方面：

(1)使用更符适用户习惯别名

(2)针对不一样级别用户定义不一样View，以满足系统对安全性要求。

(3)简化用户对系统使用第135页[例]关系模式产品（产品号，产品名，规格，单价，生产车间，生产责任人，产品成本，产品合格率，质量等级），能够在产品关系上建立两个视图：为普通用户建立视图：产品1（产品号，产品名，规格，单价）为产品销售部门建立视图：产品2（产品号，产品名，规格，单价，车间，生产责任人）用户视图中只包含允许用户查询属性销售部门视图中只包含允许销售部门查询属性生产领导部门则能够查询全部产品数据能够预防用户非法访问不允许他们查询数据，确保系统安全性7.4.3设计用户子模式第136页7.5数据库物理设计数据库物理设计数据库在物理设备上存放结构与存取方法称为数据库物理结构，它依赖于选定数据库管理系统为一个给定逻辑数据模型选取一个最适合应用环境物理结构过程，就是数据库物理设计第137页数据库物理设计步骤确定数据库物理结构，在关系数据库中主要指存取方法和存放结构对物理结构进行评价，评价重点是时间和空间效率假如评价结果满足原设计要求，则可进入到物理实施阶段，不然，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型7.5数据库物理设计第138页数据库物理设计确定数据库物理结构评价数据库物理结构逻辑结构设计数据库实施物理模型逻辑模型7.5数据库物理设计第139页7.5.1数据库物理设计内容和方法设计物理数据库结构准备工作对要运行事务进行详细分析，取得选择物理数据库设计所需参数充分了解所用RDBMS内部特征，尤其是系统提供存取方法和存放结构第140页选择物理数据库设计所需参数数据库查询事务查询关系查询条件所包括属性连接条件所包括属性查询投影属性

7.5.1数据库物理设计内容和方法第141页数据更新事务被更新关系每个关系上更新操作条件所包括属性修改操作要改变属性值每个事务在各关系上运行频率和性能要求7.5.1数据库物理设计内容和方法第142页关系数据库物理设计内容为关系模式选择存取方法(建立存取路径)

设计关系、索引等数据库文件物理存放结构7.5.1数据库物理设计内容和方法第143页7.5.2关系模式存取方法选择数据库系统是多用户共享系统，对同一个关系要建立多条存取路径才能满足多用户各种应用要求物理设计任务之一就是要确定选择哪些存取方法，即建立哪些存取路径第144页DBMS惯用存取方法索引方法当前主要是B+树索引方法经典存取方法，使用最普遍聚簇（Cluster）方法HASH方法7.5.2关系模式存取方法选择第145页一、索引存取方法选择7.5.2关系模式存取方法选择依据应用要求确定对哪些属性列建立索引对哪些属性列建立组合索引对哪些索引要设计为唯一索引第146页选择索引存取方法普通规则假如一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引)假如一个属性经常作为最大值和最小值等聚集函数参数，则考虑在这个属性上建立索引假如一个(或一组)属性经常在连接操作连接条件中出现，则考虑在这个(或这组)属性上建立索引关系上定义索引数过多会带来较多额外开销维护索引开销查找索引开销7.5.2关系模式存取方法选择第147页7.5.2关系模式存取方法选择二、聚簇存取方法选择聚簇为了提升某个属性（或属性组）查询速度，把这个或这些属性（称为聚簇码）上含有相同值元组集中存放在连续物理块称为聚簇第148页7.5.2关系模式存取方法选择聚簇用途1.大大提升按聚簇码进行查询效率例：假设学生关系按所在系建有索引，现在要查询信息系全部学生名单。信息系500名学生分布在500个不一样物理块上时，最少要执行500次I/O操作假如将同一系学生元组集中存放，则每读一个物理块可得到多个满足查询条件元组，从而显著地降低了访问磁盘次数第149页7.5.2关系模式存取方法选择2.节约存放空间聚簇以后，聚簇码相同元组集中在一起了，因而聚簇码值无须在每个元组中重复存放，只要在一组中存一次就行了第150页聚簇局限性1.聚簇只能提高某些特定应用性能2.建立与维护聚簇开销相当大对已经有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有索引无效，必须重建当一个元组聚簇码改变时，该元组存储位置也要做对应移动7.5.2关系模式存取方法选择第151页聚簇适用范围1.既适合用于单个关系独立聚簇，也适合用于多个关系组合聚簇

例：假设用户经常要按系别查询学生成绩单，这一查询包括学生关系和选修关系连接操作，即需要按学号连接这两个关系，为提升连接操作效率，能够把含有相同学号值学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”形式存放，从而大大提升连接操作效率。7.5.2关系模式存取方法选择第152页2.当经过聚簇码进行访问或连接是该关系主要应用，与聚簇码无关其它访问极少或者是次要时，能够使用聚簇。尤其当SQL语句中包含有与聚簇码相关ORDERBY，GROUPBY，UNION，DISTINCT等子句或短语时，使用聚簇尤其有利，能够省去对结果集排序操作7.5.2关系模式存取方法选择第153页设计候选聚簇对经常在一起进行连接操作关系能够建立聚簇假如一个关系一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇假如一个关系一个(或一组)属性上值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值平均元组数不太少。太少了，聚簇效果不显著7.5.2关系模式存取方法选择第154页优化聚簇设计从聚簇中删除经常进行全表扫描关系；从聚簇中删除更新操作远多于连接操作关系；不一样聚簇中可能包含相同关系，一个关系能够在某一个聚簇中，但不能同时加入多个聚簇,从这多个聚簇方案(包含不建立聚簇)中选择一个较优，即在这个聚簇上运行各种事务总代价最小7.5.2关系模式存取方法选择第155页三、HASH存取方法选择7.5.2关系模式存取方法选择选择HASH存取方法规则当一个关系满足以下两个条件时，能够选择HASH存取方法该关系属性主要出现在等值连接条件中或主要出现在相等比较选择条件中该关系大小可预知，而且不变；或该关系大小动态改变，但所选取DBMS提供了动态HASH存取方法第156页7.5.3确定数据库存放结构确定数据库物理结构内容1.确定数据存放位置和存放结构关系索引聚簇日志备份2.确定系统配置第157页1.确定数据存放位置7.5.3确定数据库存放结构确定数据存放位置和存放结构原因存取时间存放空间利用率维护代价这三个方面经常是相互矛盾例：消除一切冗余数据虽能够节约存放空间和降低维护代价，但往往会造成检索代价增加必须进行权衡，选择一个折中方案第158页基本标准依据应用情况将易变部分与稳定部分分开存放存取频率较高部分与存取频率较低部分分开存放7.5.3确定数据库存放结构第159页例：数据库数据备份、日志文件备份等因为只在故障恢复时才