目录
7.1数据库设计概述
数据库设计，广义地讲，是数据库及其应用系统的设计，即设计整个数据库应用系统；狭义地讲，是设计数据库本身，即设计数据库的各级模式并建立数据库这是数据库应用系统设计的一部分。
数据库设计的一般定义：
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
信息管理要求是指在在数据库中应该存储和管理哪些数据对象；数据操作要求是指对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。高效的运行环境指数据库的存取效率、数据库存储空间的利用率、数据库系统运行管理的效率等都是高的。
7.1.1数据库设计的特点
1.数据库建设的基本规律
在数据库建设中不仅涉及技术，还涉及管理。这里的管理不仅仅包括数据库建设作为一个大型的工程项目本身的项目管理，还包括该企业（即应用部门）的业务管理。企业的业务管理对数据库结构的设计有直接影响，这是因为数据库结构（即数据库模式）是对企业中业务部门数据以及各业务部门之间数据联系的描述和抽象。
2.结构（数据）设计和行为（处理）设计相结合
数据库设计应和应用系统设计相结合。也就是说，整个设计过程中要把数据库结构设计和对数据的处理设计密切结合起来，强调在数据库设计中要把结构特性和行为特性结合起来。
7.1.2数据库设计方法
大型数据库设计是涉及多学科的综合性技术，它要求从事数据库设计的专业人员具备多方面的知识和技术。
一般地，数据库的设计方法有新奥尔良方法、基于E-R模型的设计方法、3NF的设计方法、面向对象的数据库设计方法、统一建模语言方法等。
7.1.3数据库设计的基本步骤
1）需求分析。
2）概念结构设计。
3）逻辑结构设计。
4）物理结构设计。
5）数据库实施。
6）数据库运行和维护。
在数据库设计过程中，需求分析和概念结构设计可以独立于任何数据库管理系统进行。数据库设计开始之前，首先必须选定参加设计的人员。
1.需求分析阶段
进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。
2.概念结构设计阶段
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
3.逻辑结构设计阶段
逻辑结构设计是将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。
4.物理结构设计阶段
物理结构设计是为逻辑数据模型选取一个最适合应用环境的物理结构（包括存取结构和存取方法）。
5.数据实施阶段
在该阶段，设计人员运用数据库管理系统提供的数据库语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编写与调试应用程序，组织数据入库，并进行运试。
6.数据库运行和维护阶段
在数据库系统运行过程中必须不断地对其进行评估、调整与修改。
7.1.4数据库设计过程中地各级模式
在概念结构设计阶段形成独立于机器特点、独立于各个关系数据库管理系统产品地概念模式（即E-R图）；在逻辑结构设计阶段将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据逻辑模式，然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式；在物理结构设计阶段，根据关系数据库管理系统的特点和处理的需要进行物理存储安排，建立索引，形成数据库内模式。
7.2需求分析
7.2.1需求分析的任务
需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。
调查的重点是数据和处理，通过调查、收集与分析，获得用户对数据库的如下要求：
1）信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。
2）处理要求。指用户要完成的数据处理功能，对处理性能的要求。
3）安全性与完整性要求。
7.2.2需求分析的方法
进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。
调查用户需求的具体步骤是：
1）调查组织机构情况。
2）调查各部门的业务活动情况。
3）在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求，处理要求、安全性与完整性要求。
4）确定新系统的边界
7.2.3数据字典
数据字典是进行详细的数据收集和数据分析所获得的主要成果。它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。它在数据库设计中占有很重要的低位。
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程几部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
1.数据项
数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：
数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
其中，取值范围、与其它数据项的逻辑联系定义了数据的完整性约束条件，是设计数据检验功能的依据。
可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。即按实际语义写出每个数据项之间的数据依赖，它们是数据库逻辑设计阶段数据模型优化的依据。
2.数据结构
数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以下内容：
数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
3.数据流
数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容：
数据流描述：{数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
其中，数据流来源是说明该数据流来自哪个过程；数据流去向是说明该数据流将到哪个过程去；平均流量是指在单位时间里传输的次数；高峰期流量则是指在高峰时期的数据流量。
4.数据存储
数据存储是数据结果停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或手工凭单，也可以是计算机文档。对数据存储的描述通常包括以下内容：
数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
其中，存取频度指每小时、每天或每周存取次数及每次存取的数据量等信息；存取方式指是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等；输入的数据流要指出其来源；输入的数据流要指出其去向。
5.处理过程
处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息即可，通常包括以下内容：
处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
其中，简要说明主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么（而不是怎么做），处理要求指处理频度要求，如单位时间里处理多少事务、多少数据量等。这些处理要求是后面物理设计的输入及性能评价的标准。
强调两点：
1）需求分析阶段的一个重要而困难的任务是收集将来应用所涉及的数据，设计人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充。
2）必须强调用户的参与。
7.3概念结构设计
将需求分析得到的用户需求抽象为信息结构（及概念模式）的过程就是概念结构设计。
7.3.1概念模型
其主要特点是：
1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求，是现实世界的一个真实模型。
2）易于理解，可以用它和不熟悉计算机的用户交换意见。用户的积极参与是数据库设计成功的关键。
3）易于更改，当应用环境和应用要求改变时容易对概念模型修改和扩充。
4）易于向关系、网状、层次等各种数据模型转换。
描述概念模型的有力工具是E-R模型。
7.3.2 E-R模型
E-R模型是用E-R图来描述现实世界的概念模型。
1.实体之间的联系
实体内部的联系通常是指组成该实体的各属性之间的联系，实体之间的联系通常是指不同实体型的实体集之间的联系。
1）两个实体型之间的联系
a.一对一联系（1：1）
如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1：1。
b.一对多联系（1：n）
如果对于实体集A中的每一个实体，实体集B中有n（n>=0)个实体与之联系，反之对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B具有一对多联系，记为1：n。
例如，一个班级有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。
c.多对多联系（m：n）
如果对于实体集A中的每一个实体，实体集B中有n个实体与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体与之联系，则称实体集A与实体集B具有多对多联系，记为m：n。例如，一门课程同时有若干名学生选修，而一个学生可以同时选修多门课程，则课程与学生之间具有多对多联系。
2）两个以上的实体型之间的联系
一般地，两个以上的实体型之间也存在着一对一、一对多和多对多联系。
例如，对于课程、教师和参考书三个实体型，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师、参考书之间的联系是一对多的。
又如，有三个实体型：供应商、项目、零件，一个供应商可以供给多个项目多种零件，而每个项目可以使用多个供应商供应的零件，每种零件可由不同供给商供给，由此看出供给商、项目、零件三者之间是多对多的联系。
3）单个实体型内的联系
同一个实体集内的各实体之间也可以存在一对一、一对多和多对多的联系。例如，职工实体内部具有领导与被领导的联系，即某一职工领导若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。
一般地，把参与联系的实体型的数目称为联系的度。两个实体型之间的联系度为2，也称为二元联系；三个实体型之间的联系度为3，称为3元联系；N个实体型之间的联系度为N，也称为N元联系。
2.E-R图
E-R图提供了表示实体型、属性和联系的方法。
1）实体型用矩形表示，矩形框内写明实体名。
2）属性用椭圆形表示，并用无向边将其与相应的实体型连接起来。
3）联系用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1：1、1：n或m：n）。
需要注意的是，如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。
7.3.5概念结构设计
概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成E-R图。
1.实体与属性的划分原则
在数据字典中，数据结构、数据流和数据存储都是若干属性有意义的集合，这就已经体现了现实世界中具体的应用环境对实体和属性的自然的大体划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。在调整中遵循的一条原则是：为了简化E-R图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。
对于可以作为属性对待的事物，给出以下两条准则：
1）作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，也不能包含其它属性。
2）属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
凡是满足上述两条准则的事物，一般均可作为属性对待。
例如，职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、岗位津贴、福利挂钩，换句话说，没有需要进一步描述的特性，则根据准则（1）可以作为职工实体的属性；但如果不同的职称有不同的工资、岗位津贴和不同的附加福利，则职称作为一个实体看待就更加恰当。
又如，在医院中一个病人只能住在一个病房，病房好可以作为病人实体的一个属性；但如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则根据准则（2）病房应作为一个实体。
2.E-R图的集成
在开发一个大型信息系统时，最经常采用的策略是自顶向下地进行需求分析，然后再自底向上地设计概念结构。即首先设计各子系统的分E-R图，然后将它们集成起来，得到全局E-R图。E-R图的集成一般需要分两步走：
a.合并。解决各分E-R图之间的冲突，将分E-R图合并起来生成初步E-R图。
b.修改和重构。消除不必要的冗余，生成基本E-R图。
1）合并E-R图，生成初步E-R图
各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个子系统的E-R图之间必定会存在许多不一致的地方，称之为冲突。因此，合并这些E-R图时并不能简单地将各个E-R图画到一起，而是必须着力消除各个E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。
各个子系统的E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
A.属性冲突
a.属性域冲突，即属性值的类型、取值范围或取值集合不同。
b.属性取值单位冲突。
B.命名冲突
a.同名异义，即不同意义的对象再不同的局部应用中具有相同的名字。
b.异名同义，即同一意义的对象在不同的局部应用中具有不同的名字。
C.结构冲突
a.同一对象在不同应用中具有不同的抽象。例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。
b.同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
c.实体间的联系在不同的E-R图中为不同的类型。
2）消除不必要的冗余，设计基本E-R图
在初步E-R图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
消除冗余只要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明消除冗余。
但并不是所有的冗余数据域冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。
7.4逻辑结构设计
逻辑结构设计的主要任务就是把概念结构设计阶段设计好的E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
7.4.1 E-R图向关系模型的转换
E-R图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
关系模型的逻辑结构是一组关系模式的结合。E-R图则是由实体型、实体的属性和实体型之间的联系三个要素组成的，所有将E-R图转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式，关系的属性就是实体的属性，关系的码就是实体的码。
对于实体型间的联系有以下不同的情况：
1）一个1：1联系可以转换为一个独立的关系模式，也可以与任意一段对应的关系模式合并。如果转换为一个独立的关系模式，则该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
2）一个1：n联系可以转换为一个额独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n段实体的码。
3）一个m：n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
4）三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
5）具有相同码的关系模式可以合并。
7.4.2数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，方法为：
1）确定数据依赖。
2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
3）按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
4）根据需求分析阶段得到的处理要求分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合成或分解。
必须注意的是，并不是规范化程度越高的关系就越优。例如，当查询经常涉及两个或多个关系模式的属性时，系统经常进行连接运算。连接的运算的代价是相当高的，可以说关系模型低效的主要原因就是由连接运算引起的。
5）对关系模式进行必要的分解，提高数据操作效率和存储空间利用率。常用的两种分解方法是水平分解和垂直分解。
a.水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系，提高系统的效率。
b.垂直分解是把关系模式R的属性分解为若干子集合，系形成若干子关系模式。垂直分解的原则是，将经常在一起使用的属性从R中分解出来形成一个子关系模式。垂直分解可以提高某些事务的效率，但也可能使另一些事务不得不执行连接操作，从而降低了效率。因此是否进行垂直分解取决于分解后R上的所有事务的总效率是否得到了提高。垂直分解需要确保无损连接性和保持函数依赖，即保证分解后的关系具有无损连接性和保持函数依赖性。
7.4.3设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体关系数据库管理系统的特点设计用户的外模式。
由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便。具体包括以下几个方面：
1）使用更符合用户习惯的别名。
2）可以对不同级别的用户定义不同的视图，以保证系统的安全性。
3）简化用户对系统的使用。
7.5物理结构设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
数据库的物理设计通常分为两步：
1）确定数据库的物理结构。
2）对物理结构进行评价。
如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
7.5.1数据库物理设计的内容和方法
首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数；其次，要充分了解所用关系数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。
1)对于数据库查询事务，需要得到如下信息：
查询的关系
查询条件所设计的属性
连接条件所设计的属性
查询的投影属性
2)对于数据更新事务，需要得到如下信息：
被更新的关系
每个关系上的更新操作条件所设计的属性
修改操作要改变的属性值
除此之外，还需要知道每个事务在各关系上运行的频率和性能要求。例如，事务T必须在10s内结束，这对于存取方法的选择具有重大影响。
通常关系数据库物理结构设计的内容主要包括为关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。
7.5.2关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。
存取方法是快速存取数据库中数据的技术。数据库管理系统一般提供多种存取方法。常用的存取方法为索引方法和聚簇方法。B+树索引和hash索引是数据库中经典的存取方法。
1.B+树索引存取方法的选择
所谓选择索引存取方法，实际上就是根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计唯一索引等。一般来说：
1）如果一个属性经常在查询条件中出现，则考虑在这个属性上建立索引。
2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
3）如果一个属性经常在连接操作的连接条件中出现，则考虑在这个属性上建立索引。
关系上定义的索引并不是越多越好，因为更新一个关系时，必须对这个关系上有关的索引做相应的修改。
2.hash索引存取方法的选择
其规则如下：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一，则此关系可以选择hash存取方法。
1）一个关系的大小可以预知，而且不变。
2）关系的大小动态改变，但数据库管理系统提供了动态hash存取方法。
3.聚簇存取方法的选择
为了提高某个属性的查询速度，把这个或这些属性上具有相同值的元组集存放在连续的物理块中称为聚簇。该属性称为聚簇码。
聚簇的功能可以大大提高按聚簇码进行查询的效率。
聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系。即把多个连接关系的元组按连接属性值聚集存放。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。
一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。选择聚簇存取方法，即确定需要建立多少个聚簇，每个聚簇中包括哪些关系。
首先设计候选聚簇，一般来说：
1）对经常在一起进行连接操作的关系可以建立聚簇。
2）如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。
3）如果一个关系的一个属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不能太少，太少则聚簇的效果不明显。
必须强调的是，聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇将导致关系中元组移动其物理存储位置，并使此关系上原来建立的所有索引无效，必须重建。当一个元组的聚簇码值改变时，该元组的存储位置也要做相应移动，聚簇码值要相对稳定，以减少修改聚簇码值所引起的维护开销。
因此，当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问是很少或者是次要的，这时可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY、GROUP BY、UNION、DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作。
7.5.3确定数据库的存储结构
确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结果，确定系统配置等。
确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。
1.确定数据的存放位置
为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分与存取频率较低部分分开存放。
2.确定系统配置
关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数，供设计人员和数据库管理员对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的默认值。但这些值不一定适合每一种环境，在进行物理设计时需要重新对这些变量赋值，以改善系统的性能。
系统配置变量很多，例如，同时使用数据库的用户数，内存分配参数，缓冲区分配参数等。这些参数值影响存取时间和存取空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最佳。
7.5.4评价物理结构
数据库物理设计过程需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
7.6数据库的实施和维护
完成数据库的物理设计之后，设计人员就要用关系数据库管理系统提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，称为关系数据库管理系统可以接受的代码，再经过调试产生目标模式，然后就可以组织数据入库了，这就是数据库实施阶段。
7.6.1数据的载入和应用程序的调试
数据实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。
为提高数据输入工作的效率和质量，应该针对具体的应用环境设计一个数据录入子系统，由计算机来完成数据入库的任务。
数据库应用程序的设计应该与数据库设计同时进行，因此再组织数据入库的同时还要调试应用程序。
7.6.2数据库的试运行
在原有系统的数据有一小部分已输入数据后，就可以开始对数据库系统进行联合调试了，这又称为数据库的试运行。
这一阶段要实际运行数据库应用系统，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，对应用程序部分则要修改、调整，直到达到设计要求为止。
这里要强调两点。第一，如果试运行后还要修改数据库的设计，还要重新组织数据入库。因此应分期分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后再大批量输入数据，逐步增加数据量，逐步完成运行评价。第二，在数据库试运行阶段，由于系统还不稳定，硬、软件故障随时都可能发生等，因此要做好数据库地转储和恢复过程。一旦故障发生，能使数据库尽快恢复，尽量减少对数据库的破坏。
7.6.3数据库的运行和维护
数据库试运行合格后，数据库开发工作就基本完成，可以投入正式运行了。但是由于应用环境在不断变化，数据运行过程中物理存储结构也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。数据库的维护主要包括以下几个方面。
1.数据库的转储和恢复
2.数据库的安全性、完整性控制
3.数据库性能的监督、分析和改造
4.数据库的重组织与重构造
数据库运行一段时间后，由于记录不断增、删、改，将会使数据库的物理存储情况变坏，降低数据的存取效率，使数据库性能下降，这时数据库管理员就要对数据库进行重组织或部分重组织（只对频繁增、删的表进行重组织）。关系数据库管理系统一般都提供数据重组织用的实用程序。在重组织的过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针链等，提高系统性能。
数据库的重组织并不修改原设计的逻辑和物理结构，而数据库的重构造则不同，它是指部分修改数据库的模式和内模式。由于数据库应用环境发生变化，增加了新的应用或新的实体，取消了某些应用，有的实体与实体间的联系也发生了变化，使原有的数据库设计不能满足新的需求，需要调整数据库的模式和内模式。例如，在表中增加或删除某些数据项，改变数据项的类型等。当然数据库的重构造也是有限的，只做部分修改。如果应用变化太大，重构也无济于事，说明此数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统了。