第五篇 数据库技术数据库技术是信息系统的核心和基础，它的出现极大地促进了计算机应用向各行各业的渗透。
数据库的建设规模、数据库信息量的大小和使用频度已成为衡量一个国家信息化程度的重要标志。
5.1.1 数据库技术与数据库系统什么是数据管理？
对数据进行分类、组织、编码、存储、检索和维护，是数据处理的中心问题数据管理技术的发展过程
1,人工管理阶段(40年代中--50年代中)
应用程序，数据不保存; 无直接存取存储设备; 没有操作系统
2,文件系统阶段(50年代末--60年代中)
数据冗余度大(数据文件间是独立的,重复的)
程序与数据不独立(例身份证号位数扩大)
数据的不完整性; 缺乏对数据有效统一的控制
3,数据库系统阶段(60年代末--现在)
数据是集成的; 数据冗余少; 程序/数据独立性; 易于提供安全保障容易提供符合用户不同要求的信息。
数据库：是自描述的集成记录的集合。
用户数据（用户的表）
元数据（关于结构的描述）
应用元数据（窗体、查询、报表等应用组件）
索引信息
二 数据库管理系统（DMS）
设计工具子系统产生表、窗体、查询、报表的工具提供编程语言和对编程语言的接口运行子系统处理用设计工具开发的应用组件例：在运行期打开窗口时，自动将数据从表中提出，并显示在窗体上。
DBMS引擎从上两个组件接受请求（根据表、行和列声明），并把它们翻译成对操作系统的命令，以便读写物理介质上的数据。
5.1.2 数据描述信息世界中的基本概念
(1) 实体（Entity） 客观存在并可相互区别的事物称为实体。
可以是具体的人、事、物或抽象的概念。
(2) 属性（Attribute） 实体所具有的某一特性称为属性。
一个实体可以由若干个属性来刻画。
(3) 码（Key） 唯一标识实体的属性集称为码。
(4) 域（Domain） 属性的取值范围称为该属性的域。
(5) 实体型（Entity Type） 用实体名及其属性名集合来抽象和刻画。同类实体称为实体型
(6) 实体集（Entity Set） 同型实体的集合称为实体集
(7) 联系（Relationship）
现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系
5.1.3 数据模型在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息。通俗地讲数据模型就是现实世界的模拟数据模型应满足三方面要求能比较真实地模拟现实世界容易为人所理解便于在计算机上实现数据模型分成两个不同的层次
(1) 概念模型 也称信息模型，它是按用户的观点来对数据和信息建模。
(2) 数据模型 主要包括网状模型、层次模型、关系模型等，它是按计算机系统的观点对数据建模。
客观对象的抽象过程---两步抽象现实世界中的客观对象抽象为概念模型；
把概念模型转换为某一DBMS支持的数据模型。
概念模型是现实世界到机器世界的一个中间层次。
非关系模型层次模型（Hierarchical Model）
数据结构：树网状模型(Network Model )
数据结构：图关系模型(Relational Model)
数据结构：表
面向对象模型(Object Oriented Model）
数据结构：对象
层次模型的优缺点,典型的IMS数据库管理系统优点层次数据模型简单，对具有一对多的层次关系的部门描述自然、直观，容易理解性能优于关系模型，不低于网状模型层次数据模型提供了良好的完整性支持缺点多对多联系表示不自然对插入和删除操作的限制多查询子女结点必须通过双亲结点层次命令趋于程序化网状模型的优缺点,典型DBTG系统优点能够更为直接地描述现实世界，如一个结点可以有多个双亲具有良好的性能，存取效率较高缺点结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握
DDL、DML语言复杂，用户不容易使用关系数据模型,ORACLE,SYBASE、INFORMIX,DB/2、SQL Server、ACESS
关系模型：
关系数据形式上是一个二维表（table），表描述了一类应用对象的实例状态，表中的数据要满足完整性约束要求优点建立在严格的数学概念的基础上概念单一。数据结构简单、清晰，用户易懂易用实体和各类联系都用关系来表示。
对数据的检索结果也是关系。
关系模型的存取路径对用户透明具有更高的数据独立性，更好的安全保密性简化了程序员的工作和数据库开发建立的工作缺点,存取路径对用户透明导致查询效率往往不如非关系数据模型对象模型:以对象模型组织的数据库叫面向对象数据库对象:
封装了数据和操作，子对象继承父对象的数据和操作，类对象定义封装和继承的形式，每个实例对象只存储各属性的数据，当向该实例对象发消息时，根据实例对象查出其类对象，从中找出方法并检查无误后以实例对象的数据处理该消息。
对象式数据库的特性：检索效率高、自然合理
概念模型的用途概念模型用于信息世界的建模是现实世界到机器世界的一个中间层次是数据库设计的有力工具数据库设计人员和用户之间进行交流的语言对概念模型的基本要求较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识简单、清晰、易于用户理解。
数据库应用结构数据库系统外部的体系结构从数据库最终用户角度看单用户结构多用户结构集中式结构分布式结构客户/服务器结构（C/S）
浏览器/服务器结构（B/S）
单用户应用结构整个数据库系统(应用程序、DBMS、数据)装在一台计算机上，为一个用户独占，不同机器之间不能共享数据。
早期的最简单的数据库系统多用户结构——集中式应用结构一个主机带多个终端的多用户结构数据库系统，包括应用程序、DBMS、数据，都集中存放在主机上，所有处理任务都由主机来完成各个用户通过主机的终端并发地存取数据库，共享数据资源多用户结构——分布式结构数据库中的数据在逻辑上是一个整体，但物理地分布在计算机网络的不同结点上。
优点适应了地理上分散的公司、团体和组织对于数据库应用的需求。
缺点数据的分布存放给数据的处理、管理与维护带来困难。
当用户需要经常访问远程数据时，系统效率会明显地受到网络传输的制约。
客户／服务器结构的优点客户端的用户请求被传送到数据库服务器，数据库服务器进行处理后，只将结果返回给用户，从而显著减少了数据传输量数据库更加开放客户与服务器一般都能在多种不同的硬件和软件平台上运行可以使用不同厂商的数据库应用开发工具客户／服务器结构的缺点
“胖客户”问题：
系统安装复杂，工作量大。
应用维护困难，难于保密，造成安全性差。
相同的应用程序要重复安装在每一台客户机上，从系统总体来看，大大浪费了系统资源。
小结数据库系统构成：（DBMS、DB、应用程序、开发及使用人员）
数据库的特点：（自描述的、集成记录的集合）
模型：（对现实世界的模拟）
数据模型：面向计算机系统（关系、层次、网状、对象）
概念模型：面向用户数据建模：建立概念模型的过程实体-联系（E-R） 模型、语义对象模型数据模型三要素：
数据结构、数据操作、数据完整性约束数据库应用结构单用户结构、集中式结构、分布式结构、客户/服务器结构（C/S）、浏览器/服务器结构（B/S）
5.2 关系代数第二章 关系数据库
2.1 关系模型
2.2 关系模式
2.3 关系数据库规范化关系数据库简介系统而严格地提出关系模型的是美国IBM公司的E.F.Codd
1970年提出关系数据模型之后，提出了关系代数和关系演算的概念
1972年提出了关系的第一、第二、第三范式
1974年提出了关系的BC范式关系数据库应用数学方法来处理数据库中的数据
80年代后，关系数据库系统成为最重要、最流行的数据库系统
2.1 关系模型概述关系数据库系统是支持关系模型的数据库系统关系模型的组成关系数据结构关系操作集合关系完整性约束
关系型数据库的特点；
模型简单、数据独立性高、有较为坚实的理论基础关系：有应用语义的二维表，表中的每一行描述事物或事物的一部分的状态的数据，表中的每一列描述事物的某个特征属性：二维表中的一列就是关系模式中的一个属性。注：
表中的每一个属性必须是基本类型。
表中的每一列的所有值必须是同类型、同语义的属性的值只能是域中的值表中的每一列都必须有唯一的名字，列在表中的顺序是不重要的
1.域：属性的取值范围。
2.元组：二维表中的一行称为一个元组。
3.候选码：关系中按应用语义能唯一标识元组的最小的属性集合。
4.主码：指定为关系中元组标识的候选码，称主码属性组为主属性。主码有时也被称为主关键字或主键。
2,关系操作集合
1) 常用的关系操作查询,选择、投影、连接、除、并、交、差数据更新,插入、删除、修改查询的表达能力是其中最主要的部分
2) 关系操作的特点集合操作方式，即操作的对象和结果都是集合。
非关系数据模型的数据操作方式：一次一记录文件系统的数据操作方式
3) 关系数据语言的种类关系代数：用对关系的运算来表达查询要求的方式。（过程性的：既要知道要做什么，还要知道怎么做）
关系演算：用谓词来表达查询要求
（非过程性：是一种可以不必知道如何获得结果就能表达所要结果的语言。 ）
面向转化的语言：用关系表示的输入数据转换成用单个关系表示的结果。（非过程性化的语言，如：SQL）
按例子查询/按窗体查询：由于带有图形界面，用户可以见到一个或多个关系的具体样例。（如：Access）
4) 关系数据语言的特点关系语言是一种高度非过程化的语言能够嵌入高级语言中使用
3,关系的三类完整性约束关系的完整性是指关系中数据值与其描述的应用对象实际状态保证一致的约束条件实体完整性通常由关系系统自动支持
确保表中所有行的数据不重复（主属性不能取空值。）
例,选修（学号，课程号，成绩）
“学号、课程号”为主码，则两个属性都不能取空值。
引用完整性：
确保关联之间数据的一致性，即确保进入一个表的数据与相关的表之间数据同步。
例,学生实体、专业实体以及专业与学生间的一对多联系
学生（学号，姓名，性别，专业号，年龄）
专业（专业号，专业名）
外键（或叫外部关键字）是指一个表中的某个属性是另一个表的主关键字。
应用语义完整性：
确保数据库中的数据是有意义的。
一般用数据类型和约束来保证。
用户定义后由系统支持例：性别（男/女）
2.2 关系模式关系概念模式 关系内模式 关系外模式 两级映像
1、关系概念模式
关系概念模式主要包括出现在DB中的每个关系的说明，它包括对关系名、属性名和属性取值范围(类型)的说明。
在关系数据模型中可不说明关系与关系间的联系。关系与关系间的联系是通过连接属性实现的。
概念模式由DBMS提供的数据定义语言（ DDL ） 来定义和描述。
2.关系内模式从原理上讲，关系内模式与其他类型DBS的内模式没有什么不同，RDB中的每个基本表都应对应一个存储文件。
基于主关键字进行直接存取，一般可根据主关键字建立相应索引。
在关系内模式中不用说明存储文件，存储文件的说明由RDBMS根据基本表的定义自动映射产生。
在关系内模式主要内容中要说明的是索引。
内模式由DBMS提供的数据定义语言（ DDL ）来定义和描述。
学生：按学号升序创建惟一的聚簇索引；create unique clustered index idx_xh on 学生(学号)；
3.关系外模式外模式是概念模式的逻辑子集，是用户与DBS的接口，是对用户所用到的那部分数据的描述。
如：窗体、查询等在RDB中，外模式被称作视图(VIEW)。
外模式由DBMS提供的DDL来定义和描述。
例：在学生管理DB中，建立01001班学生的视图VIEW_01001，其结构包括学号，姓名，年龄，班级号。
create view view_01001
as select 学号,姓名,年龄,班级号
from 学生
where 班级号＝′01001′；
4.两级映像
DBS的三级模式是对数据进行三个级别的抽象，使用户能逻辑地抽象地处理数据，而不必关心数据在机器中的具体表示方式和存储方式。
为实现三个抽象级别的联系和转换，DBMS提供两个层次的映像：
⑴ 外模式/概念模式映像定义各外模式与概念模式间的映像关系。
对应于同一个概念模式可有多个外模式,每个外模式,DBS都有一个外模式/概念模式映像,它定义了该外模式与概念模式间的对应关系。
映像定义常在各自的外模式中加以描述。
⑵ 概念模式/内模式映像
定义DB全局逻辑结构与存储结构间的对应关系。
因这两级的数据结构可能不一致，即记录类型、字段类型的命名和组成可能不一样，故该映像说明概念记录和内部记录间的对应性。
概念模式/内模式映像一般是在内模式中加以描述。
映像,是一种对应规则，它指出了映像双方是如何进行转换的。
两级数据独立性
⑴ 物理数据独立性若修改DB的内模式(DB的物理结构有所变化),则只修改概念模式/内模式映像即可。
可使概念模式尽可能保持不变,即对内模式的修改尽量不影响概念模式,对外模式和应用程序的影响则更小。
⑵ 逻辑数据独立性若修改DB的概念模式(增加记录类型或增加数据项),则只修改外模式/概念模式映像,可使外模式和应用程序尽可能保持不变。
总结,DB三级模式体系结构是数据管理的结构框架,按照其组织的数据是DB的内容。
设计DB时,主要是定义DB的各级模式;在用户使用DB时,关心的是DB的内容。
DB的模式通常是相对稳定的,而DB的数据则是经常变化的。
2.3 关系模式的规范化
关系模式规范化的必要性; 数值依赖 关系的规范化
关系模式重要性原因：
它可用来表达独立于DBMS的设计规范化：
是把有问题的关系转化为两个或多个没有这些问题的关系的过程关系模式好的标准——规范化形式（范式）
范式：规定关系模式应满足的特定限制，分不同等级：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式、第四范式(4NF)、第五范式(5NF)
范式越高规范化程度越高，关系模式越好。
模式分解是关系规范化的主要方法对于有问题的关系模式，可通过模式分解的方法使之规范化。
学生关系可分解为以下三个关系：
学生（学号，姓名，所在系）
系（所在系，系主任姓名）
考试（学号，课程名，成绩）
新关系克服了学生关系存在的问题，更加合理和实用。
如何分解，涉及两个概念——关键字、函数依赖
DB中出现的数据异常现象与数据依赖有着紧密的关联。
认识和掌握函数依赖知识，对于DB的约束设计和规范化设计具有重要意义。
第一范式(1NF)
1NF：若一个关系模式R的所有属性都是不可分的基本数据项，则该关系属于1NF 。
关系模式必须是满足1NF。
满足1NF的关系模式并不一定是好的关系模式。
例如：学生(学号，姓名，所在系，系主任姓名，课程名，成绩)
存在插入异常、删除异常、更新异常和数据冗余问题第二范式(2NF)
若关系模式R属于1NF，且每个非主属性不存在部分函数依赖于主关键字，则R属于2NF 。
例：学生(学号，姓名，所在系，系主任姓名，课程名，成绩)
学生关系模式存在部分依赖：
(学号，课程名)→姓名 (学号，课程名)→所在系
(学号，课程名)→系主任姓名故不属于2NF。
对学生关系模式进行分解，使其满足2NF的条件，即要消除非主属性对主关键字的部分依赖。
学生关系模式分解成：
学生-系(学号，姓名，所在系，系主任姓名)
考试(学号，课程名，成绩)
学生-系、考试属于2NF
第三范式(3NF),若关系模式R属于1NF，且每个非主属性都不传递依赖于主关键字，则R属于3NF。
将学生-系(学号，姓名，所在系，系主任姓名)
关系模式分解为：学生(学号，姓名，所在系) 系(所在系，系主任姓名)
关系模式学生与系均已满足3NF。
3NF是一个可用的关系模式应满足的最低范式。
规范化的基本思想消除不合适的数据依赖采用“一事一地”的模式设计原则让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式上面的规范化步骤可以在其中任何一步终止设计折中规范化可以消除更新异常，但有时并不值得，有时分解前的非规范化的表可能更好，因为处理起来比较容易关系有时故意保留成非规范化的，或者规范化后又反规范化了，这样做通常是为了改善性能。将关系分解到什么程度，要根据实际情况来决定例：客户编号→邮政编码，邮政编码→（省，城市），该关系可以分解为如下两个关系：
客户（客户编号，客户名称，邮政编码），其中，“客户编号”主关键字。
编码（邮政编码，省，城市），其中，“邮政编码”是主关键字。
两个关系都属于第三范式了，但这样做可能并不一定就是好的设计，如果用户经常需要查询及生成的报表包括,客户编号、客户名、省、城市和邮政编码，则对此表不再进行分解就比较合适
5.3 数据库设计
是指在给定的应用环境下，根据用户的应用需求构造优良的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求。
数据库设计特点：
数据库设计侧重于对数据的分析和设计，数据库设计应该在整个设计过程中把结构（数据）设计和行为（处理）设计密切结合起来数据库设计应该与应用系统设计相结合结构（数据）设计：设计数据库框架或数据库结构行为（处理）设计：设计应用程序、事务处理等
需求分析的方法自顶向下的结构化分析方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并且把每一层用数据流图和数据字典描述。
① 确定系统范围。
② 确定用户对未来系统的各种要求，包括信息要求、处理要求、安全性和完整性要求。
③ 深入分析用户的业务处理，用数据流程图表达整个系统的数据的流向和对数据进行的处理，描述数据与处理间的关系。
④ 分析系统数据，产生数据字典DD，以描述数据流程图中涉及的各数据项、数据结构、数据流、数据存储和处理等。
⑴ 教学管理子系统的信息需求 (2)工资及福利管理子系统管理对象与存储信息：
①学生：学号、姓名、性别、年龄等。
②班级：班级号、班级名、人数等。
③教师：教师号、姓名、性别、职称、E-mail地址(同一教师可有多个E-mail地址)、电话号码和家庭地址(城市、区、街道、邮政编码)等。
④课程：课程号、课程名、学分、周学时、课程类型(周数)等。
⑤专业：专业号、专业名、选修门数等。
⑥系：系号、系名等。
分析
课程：课程号、课程名、学分、周学时、课程类型(周数)等。
其中：
课程类型：共同限选课、专业选修课(选修人数上限、人数下限)或必修课(课程负责人) 。
共同限选课：不分专业、面向全校学生的选修课。
专业选修课：面向本专业学生的选修课，某一专业的学生只能选修自己专业的专业选修课。每个专业都规定了学生可以选修的专业选修课的门数，不同专业所规定的选修课门数是不同的。
教学管理子系统中各对象间的联系：
①每个学生都属于一个班级，而一个班级可以有多个学生；
②每个班级属于一个专业，一个专业可以有多个班级；
③一个专业属于一个系，一个系可以有多个专业；
④一个教师属于一个系，一个系可以有多个教师；
⑤每个教师可教授多门课程，同一门课程可有不同的教师教授。但同一教师不能重复教授某门课程，教师在固定的时间和教室教授某门具体课程；
⑥每个学生可修读若干门课程(选修课或必修课)，每门课程可有多个学生修读。对任何课程学生都可申请免修不免考；
⑦某个具体的学生参加某门课程的学习，应有一个固定的教师。
⑵ 工资及福利管理子系统主要负责管理教师的工资、岗位津贴、养老金、公积金、课时奖金、住房贷款以及医疗费报销等。
管理对象与存储信息：
① 教师：教师编号、姓名、性别、工龄、职称、基本工资、养老金、公积金等。
② 课程：包括课程号、课程名、总课时等。
③ 职称：包括职称号、职称名、岗位津贴和住房贷款额等。
④ 被赡养人：包括姓名以及与教师的关系等。学校负责为被赡养人报销医药费。
工资及福利管理子系统中各对象间的联系：
①一个教师的被赡养人可有多个，而一个被赡养人仅被一个教师赡养。如果，夫妻双方都在学校工作，他们的被赡养人信息只能挂靠在其中某一人上；
②每个教师可教授多门课程，同一门课程可以有不同的教师教授，但同一个教师不能教授两门相同的课程。并假设教师在每个学期末都要接受学生的评估，而教师的课时奖金与评教等级有关；
③每个教师当前被聘任的职称是惟一的，而不同的教师可被聘同一职称。
2,概念结构设计
1．局部E-R模型的设计
2．全局E-R模型的设计
1．局部E-R模型的设计
⑴ 局部E-R模型的设计步骤
⑵ 设计教学管理子系统的E-R模型
(3) 设计工资及福利管理子系统的E-R模型
确定实体集和属性如何抽象实体和属性实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of”的关系。
例：在学校环境中，可把张三、李四等对象抽象为学生实体。
属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of”的关系。
例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。
⑴ 合并局部E-R模型
依次取出所有的局部E-R模型，进行合并，直至所有的局部E-R模型都合并完为止。在合并过程中要检查并消除局部E-R模型间的一些冲突。
冲突的种类：
① 属性冲突,指同一属性在不同局部E-R模型中有不同数据类型、取值范围或取值集合。
包括属性域冲突和属性取值单位的冲突。
② 命名冲突,
同名异义,是指具有不同意义的对象在不同的局部E-R 模型中却使用了相同的名字。
异名同义：是指具有同一意义的对象在不同的局部E-R 模型中却使用了不同的名字。
③ 结构冲突,
同一对象在不同的局部E-R模型中具有不同的抽象
如：课程实体中有课程类型属性，课程类型又作为另一实体。
同一实体在不同的局部E-R模型中包含不同的属性个数和排列次序
实体间的联系在不同的局部E-R模型中具有不同的类型。
⑵ 消除冗余数据和冗余联系
检查合并后的E-R模型中有无冗余数据和冗余联系，如有则根据实际情况消除之。
例子,教学管理与工资中，教师的职工号存在命名冲突；教师实体存在结构冲突。
三、逻辑结构设计
⑴ 任务,根据E-R模型和需求分析所产生的文档，并综合考虑所选择的具体DBMS的特点，设计整个DB的逻辑结构。
⑵ 考虑因素,包括DBMS产品的性能和价格，以及所设计的应用系统的功能复杂程度。
⑶ RDBMS产品的逻辑结构设计,指设计DB中所应包含的各个关系模式的结构，包括各关系模式的名称、每一关系模式中各属性的名称、数据类型、取值范围等内容。
⑷ 逻辑结构的设计过程,
⑸ 全局E-R模型转换成初始关系模型的规则
E-R模型中的一个常规实体集转换为一个关系模式
该关系模式的属性由原实体集中的各属性组成，关系模式的关键字也就是原实体集的关键字。
班级(班级号，班级名，人数)
学生(学号，姓名，性别，年龄)
职称(职称号，职称名，岗位津贴，住房贷款额)
课程类型(类型号，类型名，周数)
专业(专业号，专业名，选修门数)
系(系号，系名)
E-R模型中的多值属性转换为一个关系模式
E-R模型中的一个联系转换为一个关系模式
该关系模式的属性由与该联系相连的各实体集的键和联系的属性组成，该关系模式的键则应根据实体集间的联系的不同类型分别考虑。
1:1联系：与该联系相连的各实体集的关键字均可作关系模式的
关键字；
1:n联系：关系模式的关键字应是 n 端实体集的关键字；
m:n联系：关系模式的关键字由与该联系相连的各实体集的
关键字组成。
④根据实际情况，将具有相同键的关系模式合并班级(班级号，班级名，人数)
包括(班级号，专业号)
关系模式合并为：班级(班级号，班级名，人数，专业号)
学生(学号，姓名，性别，年龄)
属于(学号，班级号)
关系模式合并为：学生(学号，姓名，性别，年龄，班级号)
四,物理设计物理设计：指为给定的一个逻辑数据模型选择最适合应用环境的物理结构。
RDB的物理结构：指数据的存取方法和存储结构。
数据库物理设计的步骤：
1．确定DB的物理结构 2．评价物理结构
⑴ 设计人员必须了解的问题
① 详细了解给定的DBMS的功能和特点，特别是该DBMS所提供的物理环境和功能。
② 熟悉应用环境，了解所设计的应用系统中各部分的重要程度、处理频率、对响应时间的要求，并把它们作为物理设计过程中平衡时间和空间效率时的依据。
③ 了解外存设备的特性，如分块原则、块因子大小的规定、设备的I/O特性等等。
⑵ 物理设计的内容
①确定数据的存储结构。需考虑存取时间、空间效率和维护代价间的平衡。如在引入冗余数据以加快存取速度时应兼顾系统的空间效率。
②选择合适的存取路径。如确定该为哪些关系模式建立索引，索引关键字是什么等等。
③确定数据的存放位置。如确定数据存放在一个磁盘上还是多个磁盘上，什么数据应存放在高速存储器上，什么应存放在低速存储器上等。
④确定存取分布。许多DBMS都提供了一些存储分配参数供设计者使用。如缓冲区的大小和个数、块的长度、块因子的大小等等。设计者必须规定其中的一些参数的设置。
例1：假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。
信息系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。
如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。
例2：CREATE CLUSTER INDEX Stusname ON Student(Sname)；
在Student表的Sname（姓名）列上建立一个聚簇索引，而且Student表中的记录将按照Sname值的升序存放
例3：假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和选修关系的连接操作，即需要按学号连接这两个关系，为提高连接操作的效率，可以把具有相同学号值的学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。
五,数据库实施数据库实施的工作内容定义数据库结构组织数据入库编制与调试应用程序数据库试运行
⑵ 将原始数据装入DB
必须将分散在各个不同部门的数据抽取出来，输入计算机，并经过分类转换，使它们的结构与新系统DB的结构一致，然后才能输入到DB中去。
程序调试时需要将少部分的、适合程序调试用的数据装入到DB，系统运行正常后则需要将所有的原始数据装入到DB。
⑶ 应用程序的编制调试,与数据载入同时进行的工作是应用程序的编制和调试。
（4）DB的试运行应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。
数据库试运行也称为联合调试，其主要工作包括：
1）功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
2）性能测试：测量系统的性能指标，分析是否符合设计目标。(原因：应用程序：修改应用程序的源代码；
DB结构不合理：修改物理结构或逻辑结构)。
应经常对DB中的数据进行备份(该阶段，系统很不稳定，容易给DB中的数据造成破坏)。
六,数据库运行和维护
DBS投入运行后，由DBA对DBD进行经常性的维护工作。
⑴ DB的转储和恢复定期对DB进行备份
⑵ DB的安全性和完整性控制应根据实际情况调整
⑶ DB性能的监督、分析和改造进行分析，不断改进
⑷ DB的重组织与重构造更新操作、应用环境变化
数据库的建设规模、数据库信息量的大小和使用频度已成为衡量一个国家信息化程度的重要标志。
5.1.1 数据库技术与数据库系统什么是数据管理？
对数据进行分类、组织、编码、存储、检索和维护，是数据处理的中心问题数据管理技术的发展过程
1,人工管理阶段(40年代中--50年代中)
应用程序，数据不保存; 无直接存取存储设备; 没有操作系统
2,文件系统阶段(50年代末--60年代中)
数据冗余度大(数据文件间是独立的,重复的)
程序与数据不独立(例身份证号位数扩大)
数据的不完整性; 缺乏对数据有效统一的控制
3,数据库系统阶段(60年代末--现在)
数据是集成的; 数据冗余少; 程序/数据独立性; 易于提供安全保障容易提供符合用户不同要求的信息。
数据库：是自描述的集成记录的集合。
用户数据（用户的表）
元数据（关于结构的描述）
应用元数据（窗体、查询、报表等应用组件）
索引信息
二 数据库管理系统（DMS）
设计工具子系统产生表、窗体、查询、报表的工具提供编程语言和对编程语言的接口运行子系统处理用设计工具开发的应用组件例：在运行期打开窗口时，自动将数据从表中提出，并显示在窗体上。
DBMS引擎从上两个组件接受请求（根据表、行和列声明），并把它们翻译成对操作系统的命令，以便读写物理介质上的数据。
5.1.2 数据描述信息世界中的基本概念
(1) 实体（Entity） 客观存在并可相互区别的事物称为实体。
可以是具体的人、事、物或抽象的概念。
(2) 属性（Attribute） 实体所具有的某一特性称为属性。
一个实体可以由若干个属性来刻画。
(3) 码（Key） 唯一标识实体的属性集称为码。
(4) 域（Domain） 属性的取值范围称为该属性的域。
(5) 实体型（Entity Type） 用实体名及其属性名集合来抽象和刻画。同类实体称为实体型
(6) 实体集（Entity Set） 同型实体的集合称为实体集
(7) 联系（Relationship）
现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系
5.1.3 数据模型在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息。通俗地讲数据模型就是现实世界的模拟数据模型应满足三方面要求能比较真实地模拟现实世界容易为人所理解便于在计算机上实现数据模型分成两个不同的层次
(1) 概念模型 也称信息模型，它是按用户的观点来对数据和信息建模。
(2) 数据模型 主要包括网状模型、层次模型、关系模型等，它是按计算机系统的观点对数据建模。
客观对象的抽象过程---两步抽象现实世界中的客观对象抽象为概念模型；
把概念模型转换为某一DBMS支持的数据模型。
概念模型是现实世界到机器世界的一个中间层次。
非关系模型层次模型（Hierarchical Model）
数据结构：树网状模型(Network Model )
数据结构：图关系模型(Relational Model)
数据结构：表
面向对象模型(Object Oriented Model）
数据结构：对象
层次模型的优缺点,典型的IMS数据库管理系统优点层次数据模型简单，对具有一对多的层次关系的部门描述自然、直观，容易理解性能优于关系模型，不低于网状模型层次数据模型提供了良好的完整性支持缺点多对多联系表示不自然对插入和删除操作的限制多查询子女结点必须通过双亲结点层次命令趋于程序化网状模型的优缺点,典型DBTG系统优点能够更为直接地描述现实世界，如一个结点可以有多个双亲具有良好的性能，存取效率较高缺点结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握
DDL、DML语言复杂，用户不容易使用关系数据模型,ORACLE,SYBASE、INFORMIX,DB/2、SQL Server、ACESS
关系模型：
关系数据形式上是一个二维表（table），表描述了一类应用对象的实例状态，表中的数据要满足完整性约束要求优点建立在严格的数学概念的基础上概念单一。数据结构简单、清晰，用户易懂易用实体和各类联系都用关系来表示。
对数据的检索结果也是关系。
关系模型的存取路径对用户透明具有更高的数据独立性，更好的安全保密性简化了程序员的工作和数据库开发建立的工作缺点,存取路径对用户透明导致查询效率往往不如非关系数据模型对象模型:以对象模型组织的数据库叫面向对象数据库对象:
封装了数据和操作，子对象继承父对象的数据和操作，类对象定义封装和继承的形式，每个实例对象只存储各属性的数据，当向该实例对象发消息时，根据实例对象查出其类对象，从中找出方法并检查无误后以实例对象的数据处理该消息。
对象式数据库的特性：检索效率高、自然合理
概念模型的用途概念模型用于信息世界的建模是现实世界到机器世界的一个中间层次是数据库设计的有力工具数据库设计人员和用户之间进行交流的语言对概念模型的基本要求较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识简单、清晰、易于用户理解。
数据库应用结构数据库系统外部的体系结构从数据库最终用户角度看单用户结构多用户结构集中式结构分布式结构客户/服务器结构（C/S）
浏览器/服务器结构（B/S）
单用户应用结构整个数据库系统(应用程序、DBMS、数据)装在一台计算机上，为一个用户独占，不同机器之间不能共享数据。
早期的最简单的数据库系统多用户结构——集中式应用结构一个主机带多个终端的多用户结构数据库系统，包括应用程序、DBMS、数据，都集中存放在主机上，所有处理任务都由主机来完成各个用户通过主机的终端并发地存取数据库，共享数据资源多用户结构——分布式结构数据库中的数据在逻辑上是一个整体，但物理地分布在计算机网络的不同结点上。
优点适应了地理上分散的公司、团体和组织对于数据库应用的需求。
缺点数据的分布存放给数据的处理、管理与维护带来困难。
当用户需要经常访问远程数据时，系统效率会明显地受到网络传输的制约。
客户／服务器结构的优点客户端的用户请求被传送到数据库服务器，数据库服务器进行处理后，只将结果返回给用户，从而显著减少了数据传输量数据库更加开放客户与服务器一般都能在多种不同的硬件和软件平台上运行可以使用不同厂商的数据库应用开发工具客户／服务器结构的缺点
“胖客户”问题：
系统安装复杂，工作量大。
应用维护困难，难于保密，造成安全性差。
相同的应用程序要重复安装在每一台客户机上，从系统总体来看，大大浪费了系统资源。
小结数据库系统构成：（DBMS、DB、应用程序、开发及使用人员）
数据库的特点：（自描述的、集成记录的集合）
模型：（对现实世界的模拟）
数据模型：面向计算机系统（关系、层次、网状、对象）
概念模型：面向用户数据建模：建立概念模型的过程实体-联系（E-R） 模型、语义对象模型数据模型三要素：
数据结构、数据操作、数据完整性约束数据库应用结构单用户结构、集中式结构、分布式结构、客户/服务器结构（C/S）、浏览器/服务器结构（B/S）
5.2 关系代数第二章 关系数据库
2.1 关系模型
2.2 关系模式
2.3 关系数据库规范化关系数据库简介系统而严格地提出关系模型的是美国IBM公司的E.F.Codd
1970年提出关系数据模型之后，提出了关系代数和关系演算的概念
1972年提出了关系的第一、第二、第三范式
1974年提出了关系的BC范式关系数据库应用数学方法来处理数据库中的数据
80年代后，关系数据库系统成为最重要、最流行的数据库系统
2.1 关系模型概述关系数据库系统是支持关系模型的数据库系统关系模型的组成关系数据结构关系操作集合关系完整性约束
关系型数据库的特点；
模型简单、数据独立性高、有较为坚实的理论基础关系：有应用语义的二维表，表中的每一行描述事物或事物的一部分的状态的数据，表中的每一列描述事物的某个特征属性：二维表中的一列就是关系模式中的一个属性。注：
表中的每一个属性必须是基本类型。
表中的每一列的所有值必须是同类型、同语义的属性的值只能是域中的值表中的每一列都必须有唯一的名字，列在表中的顺序是不重要的
1.域：属性的取值范围。
2.元组：二维表中的一行称为一个元组。
3.候选码：关系中按应用语义能唯一标识元组的最小的属性集合。
4.主码：指定为关系中元组标识的候选码，称主码属性组为主属性。主码有时也被称为主关键字或主键。
2,关系操作集合
1) 常用的关系操作查询,选择、投影、连接、除、并、交、差数据更新,插入、删除、修改查询的表达能力是其中最主要的部分
2) 关系操作的特点集合操作方式，即操作的对象和结果都是集合。
非关系数据模型的数据操作方式：一次一记录文件系统的数据操作方式
3) 关系数据语言的种类关系代数：用对关系的运算来表达查询要求的方式。（过程性的：既要知道要做什么，还要知道怎么做）
关系演算：用谓词来表达查询要求
（非过程性：是一种可以不必知道如何获得结果就能表达所要结果的语言。 ）
面向转化的语言：用关系表示的输入数据转换成用单个关系表示的结果。（非过程性化的语言，如：SQL）
按例子查询/按窗体查询：由于带有图形界面，用户可以见到一个或多个关系的具体样例。（如：Access）
4) 关系数据语言的特点关系语言是一种高度非过程化的语言能够嵌入高级语言中使用
3,关系的三类完整性约束关系的完整性是指关系中数据值与其描述的应用对象实际状态保证一致的约束条件实体完整性通常由关系系统自动支持
确保表中所有行的数据不重复（主属性不能取空值。）
例,选修（学号，课程号，成绩）
“学号、课程号”为主码，则两个属性都不能取空值。
引用完整性：
确保关联之间数据的一致性，即确保进入一个表的数据与相关的表之间数据同步。
例,学生实体、专业实体以及专业与学生间的一对多联系
学生（学号，姓名，性别，专业号，年龄）
专业（专业号，专业名）
外键（或叫外部关键字）是指一个表中的某个属性是另一个表的主关键字。
应用语义完整性：
确保数据库中的数据是有意义的。
一般用数据类型和约束来保证。
用户定义后由系统支持例：性别（男/女）
2.2 关系模式关系概念模式 关系内模式 关系外模式 两级映像
1、关系概念模式
关系概念模式主要包括出现在DB中的每个关系的说明，它包括对关系名、属性名和属性取值范围(类型)的说明。
在关系数据模型中可不说明关系与关系间的联系。关系与关系间的联系是通过连接属性实现的。
概念模式由DBMS提供的数据定义语言（ DDL ） 来定义和描述。
2.关系内模式从原理上讲，关系内模式与其他类型DBS的内模式没有什么不同，RDB中的每个基本表都应对应一个存储文件。
基于主关键字进行直接存取，一般可根据主关键字建立相应索引。
在关系内模式中不用说明存储文件，存储文件的说明由RDBMS根据基本表的定义自动映射产生。
在关系内模式主要内容中要说明的是索引。
内模式由DBMS提供的数据定义语言（ DDL ）来定义和描述。
学生：按学号升序创建惟一的聚簇索引；create unique clustered index idx_xh on 学生(学号)；
3.关系外模式外模式是概念模式的逻辑子集，是用户与DBS的接口，是对用户所用到的那部分数据的描述。
如：窗体、查询等在RDB中，外模式被称作视图(VIEW)。
外模式由DBMS提供的DDL来定义和描述。
例：在学生管理DB中，建立01001班学生的视图VIEW_01001，其结构包括学号，姓名，年龄，班级号。
create view view_01001
as select 学号,姓名,年龄,班级号
from 学生
where 班级号＝′01001′；
4.两级映像
DBS的三级模式是对数据进行三个级别的抽象，使用户能逻辑地抽象地处理数据，而不必关心数据在机器中的具体表示方式和存储方式。
为实现三个抽象级别的联系和转换，DBMS提供两个层次的映像：
⑴ 外模式/概念模式映像定义各外模式与概念模式间的映像关系。
对应于同一个概念模式可有多个外模式,每个外模式,DBS都有一个外模式/概念模式映像,它定义了该外模式与概念模式间的对应关系。
映像定义常在各自的外模式中加以描述。
⑵ 概念模式/内模式映像
定义DB全局逻辑结构与存储结构间的对应关系。
因这两级的数据结构可能不一致，即记录类型、字段类型的命名和组成可能不一样，故该映像说明概念记录和内部记录间的对应性。
概念模式/内模式映像一般是在内模式中加以描述。
映像,是一种对应规则，它指出了映像双方是如何进行转换的。
两级数据独立性
⑴ 物理数据独立性若修改DB的内模式(DB的物理结构有所变化),则只修改概念模式/内模式映像即可。
可使概念模式尽可能保持不变,即对内模式的修改尽量不影响概念模式,对外模式和应用程序的影响则更小。
⑵ 逻辑数据独立性若修改DB的概念模式(增加记录类型或增加数据项),则只修改外模式/概念模式映像,可使外模式和应用程序尽可能保持不变。
总结,DB三级模式体系结构是数据管理的结构框架,按照其组织的数据是DB的内容。
设计DB时,主要是定义DB的各级模式;在用户使用DB时,关心的是DB的内容。
DB的模式通常是相对稳定的,而DB的数据则是经常变化的。
2.3 关系模式的规范化
关系模式规范化的必要性; 数值依赖 关系的规范化
关系模式重要性原因：
它可用来表达独立于DBMS的设计规范化：
是把有问题的关系转化为两个或多个没有这些问题的关系的过程关系模式好的标准——规范化形式（范式）
范式：规定关系模式应满足的特定限制，分不同等级：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式、第四范式(4NF)、第五范式(5NF)
范式越高规范化程度越高，关系模式越好。
模式分解是关系规范化的主要方法对于有问题的关系模式，可通过模式分解的方法使之规范化。
学生关系可分解为以下三个关系：
学生（学号，姓名，所在系）
系（所在系，系主任姓名）
考试（学号，课程名，成绩）
新关系克服了学生关系存在的问题，更加合理和实用。
如何分解，涉及两个概念——关键字、函数依赖
DB中出现的数据异常现象与数据依赖有着紧密的关联。
认识和掌握函数依赖知识，对于DB的约束设计和规范化设计具有重要意义。
第一范式(1NF)
1NF：若一个关系模式R的所有属性都是不可分的基本数据项，则该关系属于1NF 。
关系模式必须是满足1NF。
满足1NF的关系模式并不一定是好的关系模式。
例如：学生(学号，姓名，所在系，系主任姓名，课程名，成绩)
存在插入异常、删除异常、更新异常和数据冗余问题第二范式(2NF)
若关系模式R属于1NF，且每个非主属性不存在部分函数依赖于主关键字，则R属于2NF 。
例：学生(学号，姓名，所在系，系主任姓名，课程名，成绩)
学生关系模式存在部分依赖：
(学号，课程名)→姓名 (学号，课程名)→所在系
(学号，课程名)→系主任姓名故不属于2NF。
对学生关系模式进行分解，使其满足2NF的条件，即要消除非主属性对主关键字的部分依赖。
学生关系模式分解成：
学生-系(学号，姓名，所在系，系主任姓名)
考试(学号，课程名，成绩)
学生-系、考试属于2NF
第三范式(3NF),若关系模式R属于1NF，且每个非主属性都不传递依赖于主关键字，则R属于3NF。
将学生-系(学号，姓名，所在系，系主任姓名)
关系模式分解为：学生(学号，姓名，所在系) 系(所在系，系主任姓名)
关系模式学生与系均已满足3NF。
3NF是一个可用的关系模式应满足的最低范式。
规范化的基本思想消除不合适的数据依赖采用“一事一地”的模式设计原则让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式上面的规范化步骤可以在其中任何一步终止设计折中规范化可以消除更新异常，但有时并不值得，有时分解前的非规范化的表可能更好，因为处理起来比较容易关系有时故意保留成非规范化的，或者规范化后又反规范化了，这样做通常是为了改善性能。将关系分解到什么程度，要根据实际情况来决定例：客户编号→邮政编码，邮政编码→（省，城市），该关系可以分解为如下两个关系：
客户（客户编号，客户名称，邮政编码），其中，“客户编号”主关键字。
编码（邮政编码，省，城市），其中，“邮政编码”是主关键字。
两个关系都属于第三范式了，但这样做可能并不一定就是好的设计，如果用户经常需要查询及生成的报表包括,客户编号、客户名、省、城市和邮政编码，则对此表不再进行分解就比较合适
5.3 数据库设计
是指在给定的应用环境下，根据用户的应用需求构造优良的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求。
数据库设计特点：
数据库设计侧重于对数据的分析和设计，数据库设计应该在整个设计过程中把结构（数据）设计和行为（处理）设计密切结合起来数据库设计应该与应用系统设计相结合结构（数据）设计：设计数据库框架或数据库结构行为（处理）设计：设计应用程序、事务处理等
需求分析的方法自顶向下的结构化分析方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并且把每一层用数据流图和数据字典描述。
① 确定系统范围。
② 确定用户对未来系统的各种要求，包括信息要求、处理要求、安全性和完整性要求。
③ 深入分析用户的业务处理，用数据流程图表达整个系统的数据的流向和对数据进行的处理，描述数据与处理间的关系。
④ 分析系统数据，产生数据字典DD，以描述数据流程图中涉及的各数据项、数据结构、数据流、数据存储和处理等。
⑴ 教学管理子系统的信息需求 (2)工资及福利管理子系统管理对象与存储信息：
①学生：学号、姓名、性别、年龄等。
②班级：班级号、班级名、人数等。
③教师：教师号、姓名、性别、职称、E-mail地址(同一教师可有多个E-mail地址)、电话号码和家庭地址(城市、区、街道、邮政编码)等。
④课程：课程号、课程名、学分、周学时、课程类型(周数)等。
⑤专业：专业号、专业名、选修门数等。
⑥系：系号、系名等。
分析
课程：课程号、课程名、学分、周学时、课程类型(周数)等。
其中：
课程类型：共同限选课、专业选修课(选修人数上限、人数下限)或必修课(课程负责人) 。
共同限选课：不分专业、面向全校学生的选修课。
专业选修课：面向本专业学生的选修课，某一专业的学生只能选修自己专业的专业选修课。每个专业都规定了学生可以选修的专业选修课的门数，不同专业所规定的选修课门数是不同的。
教学管理子系统中各对象间的联系：
①每个学生都属于一个班级，而一个班级可以有多个学生；
②每个班级属于一个专业，一个专业可以有多个班级；
③一个专业属于一个系，一个系可以有多个专业；
④一个教师属于一个系，一个系可以有多个教师；
⑤每个教师可教授多门课程，同一门课程可有不同的教师教授。但同一教师不能重复教授某门课程，教师在固定的时间和教室教授某门具体课程；
⑥每个学生可修读若干门课程(选修课或必修课)，每门课程可有多个学生修读。对任何课程学生都可申请免修不免考；
⑦某个具体的学生参加某门课程的学习，应有一个固定的教师。
⑵ 工资及福利管理子系统主要负责管理教师的工资、岗位津贴、养老金、公积金、课时奖金、住房贷款以及医疗费报销等。
管理对象与存储信息：
① 教师：教师编号、姓名、性别、工龄、职称、基本工资、养老金、公积金等。
② 课程：包括课程号、课程名、总课时等。
③ 职称：包括职称号、职称名、岗位津贴和住房贷款额等。
④ 被赡养人：包括姓名以及与教师的关系等。学校负责为被赡养人报销医药费。
工资及福利管理子系统中各对象间的联系：
①一个教师的被赡养人可有多个，而一个被赡养人仅被一个教师赡养。如果，夫妻双方都在学校工作，他们的被赡养人信息只能挂靠在其中某一人上；
②每个教师可教授多门课程，同一门课程可以有不同的教师教授，但同一个教师不能教授两门相同的课程。并假设教师在每个学期末都要接受学生的评估，而教师的课时奖金与评教等级有关；
③每个教师当前被聘任的职称是惟一的，而不同的教师可被聘同一职称。
2,概念结构设计
1．局部E-R模型的设计
2．全局E-R模型的设计
1．局部E-R模型的设计
⑴ 局部E-R模型的设计步骤
⑵ 设计教学管理子系统的E-R模型
(3) 设计工资及福利管理子系统的E-R模型
确定实体集和属性如何抽象实体和属性实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of”的关系。
例：在学校环境中，可把张三、李四等对象抽象为学生实体。
属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of”的关系。
例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。
⑴ 合并局部E-R模型
依次取出所有的局部E-R模型，进行合并，直至所有的局部E-R模型都合并完为止。在合并过程中要检查并消除局部E-R模型间的一些冲突。
冲突的种类：
① 属性冲突,指同一属性在不同局部E-R模型中有不同数据类型、取值范围或取值集合。
包括属性域冲突和属性取值单位的冲突。
② 命名冲突,
同名异义,是指具有不同意义的对象在不同的局部E-R 模型中却使用了相同的名字。
异名同义：是指具有同一意义的对象在不同的局部E-R 模型中却使用了不同的名字。
③ 结构冲突,
同一对象在不同的局部E-R模型中具有不同的抽象
如：课程实体中有课程类型属性，课程类型又作为另一实体。
同一实体在不同的局部E-R模型中包含不同的属性个数和排列次序
实体间的联系在不同的局部E-R模型中具有不同的类型。
⑵ 消除冗余数据和冗余联系
检查合并后的E-R模型中有无冗余数据和冗余联系，如有则根据实际情况消除之。
例子,教学管理与工资中，教师的职工号存在命名冲突；教师实体存在结构冲突。
三、逻辑结构设计
⑴ 任务,根据E-R模型和需求分析所产生的文档，并综合考虑所选择的具体DBMS的特点，设计整个DB的逻辑结构。
⑵ 考虑因素,包括DBMS产品的性能和价格，以及所设计的应用系统的功能复杂程度。
⑶ RDBMS产品的逻辑结构设计,指设计DB中所应包含的各个关系模式的结构，包括各关系模式的名称、每一关系模式中各属性的名称、数据类型、取值范围等内容。
⑷ 逻辑结构的设计过程,
⑸ 全局E-R模型转换成初始关系模型的规则
E-R模型中的一个常规实体集转换为一个关系模式
该关系模式的属性由原实体集中的各属性组成，关系模式的关键字也就是原实体集的关键字。
班级(班级号，班级名，人数)
学生(学号，姓名，性别，年龄)
职称(职称号，职称名，岗位津贴，住房贷款额)
课程类型(类型号，类型名，周数)
专业(专业号，专业名，选修门数)
系(系号，系名)
E-R模型中的多值属性转换为一个关系模式
E-R模型中的一个联系转换为一个关系模式
该关系模式的属性由与该联系相连的各实体集的键和联系的属性组成，该关系模式的键则应根据实体集间的联系的不同类型分别考虑。
1:1联系：与该联系相连的各实体集的关键字均可作关系模式的
关键字；
1:n联系：关系模式的关键字应是 n 端实体集的关键字；
m:n联系：关系模式的关键字由与该联系相连的各实体集的
关键字组成。
④根据实际情况，将具有相同键的关系模式合并班级(班级号，班级名，人数)
包括(班级号，专业号)
关系模式合并为：班级(班级号，班级名，人数，专业号)
学生(学号，姓名，性别，年龄)
属于(学号，班级号)
关系模式合并为：学生(学号，姓名，性别，年龄，班级号)
四,物理设计物理设计：指为给定的一个逻辑数据模型选择最适合应用环境的物理结构。
RDB的物理结构：指数据的存取方法和存储结构。
数据库物理设计的步骤：
1．确定DB的物理结构 2．评价物理结构
⑴ 设计人员必须了解的问题
① 详细了解给定的DBMS的功能和特点，特别是该DBMS所提供的物理环境和功能。
② 熟悉应用环境，了解所设计的应用系统中各部分的重要程度、处理频率、对响应时间的要求，并把它们作为物理设计过程中平衡时间和空间效率时的依据。
③ 了解外存设备的特性，如分块原则、块因子大小的规定、设备的I/O特性等等。
⑵ 物理设计的内容
①确定数据的存储结构。需考虑存取时间、空间效率和维护代价间的平衡。如在引入冗余数据以加快存取速度时应兼顾系统的空间效率。
②选择合适的存取路径。如确定该为哪些关系模式建立索引，索引关键字是什么等等。
③确定数据的存放位置。如确定数据存放在一个磁盘上还是多个磁盘上，什么数据应存放在高速存储器上，什么应存放在低速存储器上等。
④确定存取分布。许多DBMS都提供了一些存储分配参数供设计者使用。如缓冲区的大小和个数、块的长度、块因子的大小等等。设计者必须规定其中的一些参数的设置。
例1：假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。
信息系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。
如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。
例2：CREATE CLUSTER INDEX Stusname ON Student(Sname)；
在Student表的Sname（姓名）列上建立一个聚簇索引，而且Student表中的记录将按照Sname值的升序存放
例3：假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和选修关系的连接操作，即需要按学号连接这两个关系，为提高连接操作的效率，可以把具有相同学号值的学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。
五,数据库实施数据库实施的工作内容定义数据库结构组织数据入库编制与调试应用程序数据库试运行
⑵ 将原始数据装入DB
必须将分散在各个不同部门的数据抽取出来，输入计算机，并经过分类转换，使它们的结构与新系统DB的结构一致，然后才能输入到DB中去。
程序调试时需要将少部分的、适合程序调试用的数据装入到DB，系统运行正常后则需要将所有的原始数据装入到DB。
⑶ 应用程序的编制调试,与数据载入同时进行的工作是应用程序的编制和调试。
（4）DB的试运行应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。
数据库试运行也称为联合调试，其主要工作包括：
1）功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
2）性能测试：测量系统的性能指标，分析是否符合设计目标。(原因：应用程序：修改应用程序的源代码；
DB结构不合理：修改物理结构或逻辑结构)。
应经常对DB中的数据进行备份(该阶段，系统很不稳定，容易给DB中的数据造成破坏)。
六,数据库运行和维护
DBS投入运行后，由DBA对DBD进行经常性的维护工作。
⑴ DB的转储和恢复定期对DB进行备份
⑵ DB的安全性和完整性控制应根据实际情况调整
⑶ DB性能的监督、分析和改造进行分析，不断改进
⑷ DB的重组织与重构造更新操作、应用环境变化
