1.概述
数据库设计是指在现有的应用环境下，从建立问题的概念模型开始，逐步建立和优化问题的逻辑模型，最后建立其高效的物理模型，并据此建立数据库及其应用系统，使之能够有效地收集、存储和管理数据，满足用户的各种应用需求。
数据库设计最终目的：（1）满足用户的需求；（2）简化应用程序的编程设计，实现系统协同、高效的开发，减少开发成本。
数据库设计步骤：系统需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库系统运行和维护。
各步骤的先后关系如图3.1所示。其中，对每一个步骤，如果设计结果不满足要求，都有可以返回前面的任一步骤，直到满足要求为止。
2. 需求分析
需求分析是了解用户需求、然后明确用户需求、最后形成需求文字表达（需求分析说明书）的一个过程。需求分析的最终结果就是形成一份有效的需求分析说明书。
2.1 系统调研过程
系统调研也称项目调研，即把系统开发当作项目来运作，其主要目的是通过接触用户以了解并最终明确用户的实际需求。这个过程是一个系统分析人员理解和掌握用户业务流程的过程，是一个需要不断与用户进行沟通和磋商的过程。系统调研方法比较灵活，因人、因系统而异。大致过程可以分为以下几个步骤来完成：
充分了解项目背景以及开发的目的。
深入用户单位（指使用该系统的机构和组织）进行调查。包括了解单位的组织结构、运作方式，了解各部门的职责和功能。然后从数据流的角度分析各个部分的特性以及它与其他部门之间的关系，如各部门的输入（输出）数据及其格式是什么，这些数据来自哪里、去向何方等，并作相应的记录。
这个步骤是调查的重点，而且难度比较大，难点在于如何建立与用户理性的沟通渠道。用户与系统分析人员一般都具有不同的技术背景，所以经常导致这种情况的出现：用户认为已经说清楚了的东西而分析人员也许对之还不能理解，或者用户提出的要求过高，超出了计算机能够处理的范围等。当出现这种情况时，需要分析人员不断的询问或说明，久了就会导致用户的厌倦。在进行这项调查前分析人员应该做好充分的准备，例如拟好调查方案、设计合理而简洁的调查表等。
给出了一种调查方法，可供读者参考和选用：
单位情况及其运作方式的介绍。
对部门工作职能的深入了解。
召开调查会。
如果与用户还没有就需求达成共识，相关分析人员可有选择地重复②和③步。
确定用户需求、明确系统功能和边界。综合各个分析人员的调查结果，形成系统的功能说明，确定哪些功能是系统要实现的，哪些是不应该实现的，或者是不能实现的。所有这些结果都应该跟用户确认后予以书面形式确定下来。
2.2 需求分析的方法
2.2.1 SA方法
针对数据库设计，形成用户需求的有效表达，这种表达在说明书中多以数据流图、数据字典等形式来描述。
为建立用户需求的表达，可以采用多种分析方法来完成。这些方法主要包括自顶向下和自底向上两种方法，其中常采用的方法是自顶向下的结构化分析方法（SA, structured analysis）。
SA方法的分析过程符合人类对问题的认识并最终解决的一般过程，其分析过程简单、实用，现已在众多领域中得到应用。
SA特点可以归结为一棵树的产生过程：先创建树根，然后创建树根节点的子节点，接着创建各子结点的子节点，直到创建所有的树叶节点为止。在这棵树中，树根节点相当于整个系统（第一层次上的系统），其子节点相当于第二层次上的系统，…，最后层次上的系统由叶子节点表示，它对系统分析人员是可认知的（认为已经清楚而不必再分解了）。自顶向下的SA方法是从整个系统开始，采用逐层分解的方式对系统进行分析的方法。
2.2.2 数据流图（data flow diagram）
SA方法只是对问题分析的一种思想，在具体的分析过程中还需要借助其他的分析工具，这样才能完成对分析过程和结果的记录、对用户需求的表达等，数据流图就是最为常用的辅助分析工具和描述手段。
数据流图是以图形的方式来刻画数据处理系统中信息的转变和传递过程，是对现实世界中实际系统的一种逻辑抽象表示，但又独立于具体的计算机系统。
数据流图常采用的符号：
数据流
数据流是流动中的数据。所以数据流图是用有方向的曲线或直线来表示，用前头表示数据流的方向，其旁边标以数据流的名称，其格式如下：
数据流名不是随意取的，它能够简要地概括数据流的含义，且易于理解。下文提到的数据名、加工名、文件名等都有同样的要求。
数据流可以来自数据的源点、加工和数据文件，可以流向数据的终点、加工和数据文件。当数据取自文件或者流向文件时，相应的有向直线或曲线可以不命名，因为从相应的文件中即可知道流动的是什么数据。
数据的源点和终点
系统中的数据是来自系统以外的其他数据对象，其最终的流向也是系统以外的有关数据对象。
这种向系统提供数据的数据对象统称为系统的数据源点，而系统数据所流向的数据对象则统称为数据终点。这两个概念的引入是为了帮助用户对系统接口界面的理解。
在数据流图中，数据源点和数据终点都是用方框来表示，方框中标以数据的名称。其格式如下：
加工
加工是对数据处理的一个抽象表示。如果这种“加工”还不为系统分析员所理解，则需要SA方法对其进行分解，直到所得到的加工已经足够简单、不必再分时为止。这时的加工也称为基本加工。在数据流图中，加工是用圆圈（或椭圆）表示，圆圈标以加工的名称。其格式如下：
数据文件
数据文件是表示数据临时存放的地方，“加工”能够对其进行数据读取或存入。在数据流图中，数据文件通常用平行的双节线表示，旁边标以数据文件名。其格式如下：
对于数据流图中的一个节点，可能有几条表示数据流的有向线出自或指向该节点。该节点对数据流的影响方式（流出情况）或这几股数据流对该节点的作用方式是有多种的。这种影响和作用方式说明如表3.1所示。
2.2.3基于数据流图的SA方法
自顶向下的SA分析方法可以与数据流图有机地结合起来，将对系统的分析过程和结果形象地表示出来。
在数据流图中，SA分析方法主要体现在对“加工”进行分解的过程。对数据流图的绘制和分解过程就是用户需求的分析及其表达的形成过程。
一个系统的数据流图是由多个子图构成，如果加上子图之间的分解关系，就可以形成一棵树。但由于所有的子图通过表示分解关系的边连在一起而形成的树将是很庞大的，无法在同一平面中画出，所以在绘制数据流图时要分为多个子图来画。
绘制的原则一般是，先绘制树根节点对应的子图，然后绘制根节点的子节点所对应的子图，一直绘制到所有叶子节点对应的子图为止。
下面以某中石化集团的样品分析管理系统（一个子系统）的开发为例，介绍数据流图的基本绘制方法。
1）绘制根节点图。从加工粒度上看，根节点图（即根节点对应的数据流图）是最大的数据流图，它是将整个应用系统当作一个加工。
【例子】 对于样品分析管理系统（YPFXMS），其根节点子图如图3.2所示。
2）绘制子节点图。数据流图的根节点不提供任何有用的信息，需要对加工“样品分析管理系统”作进一步的分解。在调研中发现，不是每一种样品都需要分析的，能够分析的是那些已经有计算公式或分析方案的样品，而且送样（被送用于分析的样品）要先存在样品分析员那里，样品分析员则按照某一个原则一次对这些送样进行分析。在送样被分析，还需要对分析的结果进行检查，如果发现分析结果不合格（是指分析手段和方法出错）则返回给样品分析员重新进行分析，分析合格则返回给送样人员。于是，分解后得到如图3.3所示的数据流图。
2.2.4 形成数据字典
数据流图主要是表示数据和处理之间的关系，但缺乏对数据流、数据文件、加工等图中各个元素进行描述的能力。
数据流图是将用户头脑中的需要转化为机器能够接受的表达的一个中转站，但数据流图表示的信息离机器能够接受的信息还比较远。如果把用户需求和机器表示放在两头，数据流图放在两者之间，那么数据流图更靠近用户需求一些，而相对远离机器表示。
需要引入数据字典的概念，通过数据字典可以加强数据流图的信息表达能力，同时这种表达拉近了与机器表示的距离，使得用户需求从纯粹的逻辑表达逐步转向机器表示，为数据库的实施奠定基础。
与数据流图一样，数据字典也是SA方法中一种有力的工具。数据字典与数据流图结合使用，主要是用于对数据流图中出现的各种元素进行描述，给出所有数据元素的逻辑定义。数据字典是数据流图中数据元素的描述。这种描述是由一系列的条目组成，但不同的应用、不同的系统其组成的条目可能有所不同。至少应该包括数据流、数据文件、加工和数据项等四种条目。
数据项条目
数据项是数据构成的最小组成单位，它不能再分割。数据项条目用于说明数据项的名称、类型、长度、取值范围等。
例如，在课题管理系统中数据项“课题申请代码”条目可描述如下：
数据项名：课题申请代码
类型：字符型
长度：12
取值范围：000000000000～999999999999
取值说明：前4为年号，第5到第6位、第7到第8位分别表示月份和日期，后4位表示 当天的课题序号
数据流条目
数据流条目主要用于说明数据流的组成（由哪些数据项组成），数据流的来源和流向以及数据流量等信息。
例如，数据流“样品分析请求信息”条目描述如下：
数据流名称：样品分析请求信息
组成：申请表编号、申请表名称、分析项目代码、样品编号、
样品名称、送样日期、送样人员
来源：记录送样信息（加工）
去向：样品分析请求信息（文件）
流量：10～20/每天
数据文件条目
数据文件条目用于说明数据文件是由哪些数据项组成，组织方式、存储频率如何等信息。
例如，数据文件“一审合格实验信息”条目如下：
文件名：一审合格实验信息
数据组成：试验记录表编号、试验记录表名称、试验日期、试验环境、试验目的、 操作人员、原料规格、试验配方与工艺、操作过程与现象、
试验结果与讨论、记录人员、试验组长、课题代码
组织方式：按试验记录表编号递增排列
存储频率：1次/天
加工条目
加工条目主要用于说明加工的逻辑功能、指明输入数据和输出数据等信息。其中逻辑功能项用于指出该加工用来做什么、对加工处理的一些要求等。
例如，
加工编号：1
加 工 名：记录送样信息
输入数据：样品数据
输出数据：样品分析请求信息
逻辑功能：对送检的样品数据进行登记，并由此转化成样品分析请求信息。
3. 数据库结构设计
3.1 概念结构设计
3.1.1概念结构定义
需求分析的成果是数据流图和数据字典，概念结构设计的目的就是将抽象转化为信息世界中基于信息结构表示的数据结构——概念结构，即概念结构是用户需求在信息世界中的模型。
数据库的概念结构独立于它的逻辑结构，更与数据库的物理结构无关。它是现实世界中用户需求与机器世界中机器表示之间的中转站。它既有易于用户理解、实现分析员与用户交流的优点，也有易于转化为机器表示的特点。当用户的需求发生改变时，概念结构很容易作出相应的调整。所以，概念结构设计是数据库设计的一个重要步骤。
概念模式描述的经典工具是E-R图，由E-R图表示的概念模型就是所谓的E-R模型。E-R模型的创建和设计过程就是概念结构的创建和设计过程，概念结构的设计集中体现为E-R模型的设计。
E-R模型的优点：
它具有较强的表达能力，可以充分表示各种类型数据及数据之间的联系；
数据表达形式简单，没有过多的概念，定义严格，无二义性等；
E-R模型是以图形的形式出现，表示直观。
3.1.2设计思想
四种概念结构的设计指导思想：
自顶向下：首先根据用户需求定义全局概念结构的E-R模型，然后对其分解，逐步细化。
自底向上：首先根据各个部门的需求定义局部概念结构的E-R模型，然后将这些局部的E-R模型并接成为全局的E-R模型，形成全局概念结构。
先主后次：分析各种子需要的“轻重”，首先设计最重要的概念结构，形成它的E-R模型，然后定义次要概念结构的E-R模型，接着按照类似的方法定义其他所有概念结构的E-R模型，最后将这些模型继承起来，形成全局概念结构。
上下混合：这是指将自顶向下和自底向上这两种方法结合起来使用的一种设计方法。
概念结构设计通常采用的是自底向上的设计方法（而需求分析一般是采用自顶向下的方法），即这种方法分为两步：
- 先建立局部概念结构的E-R模型；
- 然后将所有的局部E-R模型集成起来形成全局概念结构。
以下主要介绍这种自底向上的概念结构设计方法：
步骤一： 局部E-R模型的设计
E-R模型的设计基于需求分析阶段产生的数据流图和数据字典来进行。一个系统的数据流图是按分层来绘制，是由多张数据流图构成。基于一张数据流图及其对应的数据字典部分进行的E-R模型设计得到的是一个局部概念。
实体和实体间联系的划分并无统一的标准，一般采用的划分原则是，先是凭经验，后再作调整。
经验是指在一般情况下对于那些具有共同特征和行为的对象，可以将之抽象为实体；对象的共同特征和行为可以抽象为实体的属性。
调整是指在凭经验作出抽象后，根据具体的应用和建模环境对实体与其属性之间的关系以及实体与实体之间的关系作出相应的更改，有可能使得原来的属性变为实体，原来是实体的变为属性等，从而也导致了实体间关系的改变。
实体及实体间关系的抽象注意以下三点：
（1）在同一应用环境中，被抽象为属性的事物就不能再被抽象为实体了，否则会导致“属性又包含属性”的错误，这违反第一范式；
（2）属性具有不可再分性，所以具有不可再分性的事物一般都应抽象为属性，而具有可再分性的事物一般不能抽象为属性；
（3）一个事物不能同时被抽象为两个实体的属性，即一个属性只能隶属于一个实体。
【例子】 对于一个企业信息管理系统来说，企业中的工作人员可以抽象为“职工”实体，而工作人员的姓名、性别、年龄、职称、所在部门等可以抽象为“职工”实体的属性，如图3.4所示。
【例子】 如果在这个系统中除了“职工”信息以外还需要考虑部门的一些信息，如部门的名称、人数、经理、位置等信息，那就应该对前面的抽象作调整：应该将“部门”由原来作为“职工”的属性改为一个新的实体——“部门”实体，同时原来作为属性的“部门”被删除（这避免了一个事物既作为属性又作为实体的情况出现）。这两个实体的关系是“部门”拥有“职工”（或者“职工”隶属于“部门”），即“拥有”是这两个实体之间的联系。这样，原来的E-R图进一步得到调整和扩充，如图3.5所示。
从需求分析中发现，部门中的职工所做的工作是开发项目，用于说明项目的信息包括项目名称、项目性质、项目开发的起始时间、项目经费、项目经理等。将项目抽象为实体，形成“项目”实体，其E-R图如图3.6所示。
步骤二：全局E-R模型的集成
相对于一个整体而言，以上是E-R局部图，这些E-R图应该能够合成一张总的E-R图。对概念结构来说，就是将局部概念结构集成为全局的概念结构。
【例子】 根据需求分析结果，在这个企业中每个部门都有承接多个项目的可能，每个职工只参加一个项目。将图3.5和图3.6所示的E-R图并接起来，结果得到了整个系统的E-R图，如图3.7所示。
局部E-R图的并接过程中产生许多问题，这些问题主要体现为各个局部E-R图之间的冲突，其中包括命名冲突、属性冲突和结构冲突等。
- 命名冲突
命名冲突是指意义不同的元素在不同的局部E-R图中有相同的名字，或者是有相同意义的元素在不同的局部E-R图中具有不相同的名字。
- 属性冲突
属性冲突是指同义同名的属性在不同的局部E-R图中的取值类型、范围、所使用的单位等却完全不一样。
【例子】 有的将职工编号定义为长度为12个字节的字符串类型，有的则定义为8个字节的字符串类型，有的可能将职工编号定义为整型。
在一个E-R图中不应该存在属性冲突。
- 结构冲突
结构冲突是指一个事物在一个局部E-R图被抽象为实体，而在另一个局部E-R图中又被抽象为属性。
这不能直接将这两个局部E-R图并接为一个E-R图，首先要解决结构冲突问题。解决的办法是，视具体情况将相应的属性改为实体，或者将相应的实体改为属性。
还有一种结构冲突是相同的实体在不同的局部E-R图中有不同的属性或不同的联系。对于前一种情况，一种简单的解决方法是：使该实体的属性集为它在各E-R图中的属性集的并；对于后一种情况，解决方法相对复杂，要视具体情况对联系进行分解，或者进行其他的调整。
在构建的E-R图中，最好不要包含环形结构，因为这容易出现“死循环”参照关系。
【例子】 假设实体X、Y和Z以及它们之间的联系a、b和c构成如图3.8所示的E-R图，则该E-R图出现“死循环”问题，因为在据此图建立数据表时，将出现X参照Y、Y参照Z、Z参照X的“死循环”参照关系，从而无法创建数据表。因此，如果一个E-R图包含环形结构，则需要进一步确认对概念结构的建模是否正确？重新修改E-R图，或者直接将环中的一条边（关联）去掉，以破坏“死循环”结构。
3.1.3步骤
概念结构设计中，实体集中的实体彼此是可区别的。如果实体集中的属性或最小属性组合的值能唯一标识其对应实体，则将该属性或属性组合称为码。对于每一个实体集，可指定一个码为主码。
如果用矩形框表示实体集，用带半圆的矩形框表示属性，用线段连接实体集与属性，当一个属性或属性组合指定为主码时，在实体集与属性的连接线上标记一斜线，则可以用图1.4描述学生成绩管理系统中的实体集及每个实体集涉及的属性。
图1.4 学生和课程实体集属性的描述 其中 主键
1．一对一的联系（1 : 1）
A中的一个实体至多与B中的一个实体相联系，B中的一个实体也至多与A中的一个实体相联系。例如，“班级”与“正班长”这两个实体集之间的联系是一对一的联系，因为一个班级只有一个正班长，反过来，一个正班长只属于一个班级。“班级”与“正班长”两个实体集的E-R模型如图1.5所示。
2．一对多的联系（1 : n）
A中的一个实体可以与B中的多个实体相联系，而B中的一个实体至多与A中的一个实体相联系。例如，“班级”与“学生”这两个实体集之间的联系是一对多的联系，因为，一个班级可有若干学生，反过来，一个学生只能属于一个班级。“班级”与“学生”两个实体集的E-R模型如图1.6所示。
3．多对多的联系（m : n）
A中的一个实体可以与B中的多个实体相联系，而B中的一个实体也可与A中的多个实体相联系。例如，“学生”与“课程”这两个实体集之间的联系是多对多的联系，因为，一个学生可选多门课程，反过来，一门课程可被多个学生选修。“学生”与“课程”两个实体集的E-R模型如图1.7所示。
注意：实体图ER图可以分开
3.2 逻辑结构设计
数据库的逻辑结构设计就是将以E-R图表示的概念结构转换为DBMS支持的数据模型并对其进行优化的过程。
概念结构是由E-R图来描述的，概念结构到关系模型的转换可以归结为E-R图到关系模型的转换问题。E-R图的基本元素是实体、属性和联系等，于是E-R图到关系模型的转换就变成了实体、属性和联系等基本元素到关系模式的转化问题。
1. 实体和属性的转变
这种转变比较简单、直观，即一个实体转化为一个关系模式，其中实体名变成了关系模式的名称，实体属性相应地变成了关系的属性。
【例子】 图3.7中的三个实体分别转化为以下三个关系模式：
项目（编号，名称，经理，性质，启动时间，结题时间，经费）
部门（编号，名称，经理，人数，地址）
职工（编号，姓名，性别，职称，年龄）
2. （1:1）联系的转变
一对一联系的转变：创建一个独立的关系模式，该关系模式的属性是由该联系本身的属性以及与之相连的实体的候选码（每个实体中取一个候选码）组成。
1 : 1联系的E-R图到关系模式的转换
1∶1的联系既可单独对应一个关系模式，也可以不单独对应一个关系模式。
可以放在一个里，不用单建表
（1）联系单独对应一个关系模式，则由联系属性、参与联系的各实体集的主码属性构成关系模式，其主码可选参与联系的实体集的任一方的主码。
例如，对于图1.5描述的“班级（BJB）”与“正班长（BZB）”实体集通过属于（SYB）联系E-R模型，可设计如下关系模式（下横线表示该字段为主码）：
BJB（班级编号，院系，专业，人数 ）
BZB（学号，姓名）
SYB（学号，班级编号）
（2）联系不单独对应一个关系模式，联系的属性及一方的主码加入另一方实体集对应的关系模式中。
例如，对于图1.5描述的“班级（BJB）”与“正班长（BZB）”实体集通过属于（SYB）联系E-R模型，可设计如下关系模式：
BJB（班级编号，院系，专业，人数）
BZB（学号，姓名，班级编号）
或者
BJB（班级编号，院系，专业，人数，学号）
BZB（学号，姓名）
【例子】 一个仓库仅由一个仓库管理员管理，而一个仓库管理员也只能管理一个仓库，所以仓库管理员和仓库之间的联系是管理，管理时间为8小时（一天），其E-R图如图3.9所示。
“仓库管理员”和“仓库”之间的联系是（1:1），该联系转换后形成如下的关系模式：管理（管理员编号，仓库编号，时间）
管理员编号和仓库编号分别为“仓库管理员”实体和“仓库”实体的候选码，时间是“管理”联系的属性。
有时候为了减少数据冗余，可以将联系对应的关系合并到与之相连的某一个实体对应的关系中去。
方法：将一个实体的候选码以及联系的属性添加到另一个实体对应的关系中。
【例子】 对于以上例子，易知“仓库管理员”实体对应的关系如下：
仓库管理员（管理员编号，姓名）
我们只需将“仓库”实体的候选码“仓库编号”以及联系的属性“时间”一起添加到仓库管理员关系中即可，从而实现对联系“管理”的转换，结果得到的关系模式如下：
仓库管理员（管理员编号，姓名，仓库编号，时间）
也可以将“仓库管理员”的候选码和联系的属性“时间”一起添加到仓库关系中，结果得到如下的关系模式：
仓库（仓库编号，仓库规模，管理员编号，时间）
联系可以合并到任意与之相连的实体对应的关系中。但在实际应用，往往从效率的角度来考虑如何进行合并。
3.（1:n）联系的转变
一对多联系可以转化为一个独立的关系模式，也可以将联系合并到n端对应的关系模式中。
可以放在一个里，不用单建表
【例子】 对于图3.7所示的E-R图，“拥有”联系是一对多联系，当把这个联系转化为独立的关系模式时，则得到如下的关系模式：
拥有（职工.编号，部门.编号）
用合并的方法对该联系进行转换，则得到如下的关系模式：
职工（职工.编号，姓名，性别，年龄，职称，部门.编号）
其中，以上的“编号”属性都是相应实体的主码。
1 : n联系的E-R图到关系模式的转换
1∶n的联系既可单独对应一个关系模式，也可以不单独对应一个关系模式。
（1）若联系单独对应一个关系模式，则由联系的属性、参与联系的各实体集的主码属性构成关系模式，n端的主码作为该关系模式的主码。
例如，对于图1.6描述的“班级（BJB）”与“学生（XSB）”实体集E-R模型，可设计如下关系模式：
BJB（班级编号，院系，专业，人数）
XSB （学号，姓名，性别，出生时间，专业，总学分，备注）
SYB （学号，班级编号）
（2）若联系不单独对应一个关系模式，则将联系的属性及1端的主码加入n端实体集对应的关系模式中，主码仍为n端的主码。
例如，对于图1.6描述的“班级（BJB）”与“学生（XSB）”实体集E-R模型，可设计如下关系模式：
BJB（班级编号，院系，专业，人数）
XSB （学号，姓名，性别，出生时间，专业，总学分，备注，班级编号）
4.（m:n）联系的转变
多对多必须建立一个表
多对多联系只能转换为一个独立的关系模式，其属性集是由与该联系相连的实体的属性（码）以及该联系本身的属性转换而得到的。
【例子】 一个仓库可以存放多种零件，一种零件也可以存放在多个仓库中，可见仓库和零件之间的联系——“存放”是（m:n）联系。假设其E-R图如图3.10所示。
“存放”联系转换为独立的关系模式后，结果如下：
存放（仓库编号，零件编号，数量）
m : n联系的E-R图到关系模式的转换
m : n的联系单独对应一个关系模式，该关系模式包括联系的属性、参与联系的各实体集的主码属性，该关系模式的主码由各实体集的主码属性共同组成。
例如，对于图1.7描述的“学生（XSB）”与“课程（KCB）”实体集之间的联系可设计如下关系模式：
XSB（学号，姓名，性别，出生时间，专业，总学分，备注）
KCB（课程号，课程名称，开课学期，学时，学分）
CJB（学号，课程号，成绩）
关系模式CJB的主码是由“学号”和“课程号”两个属性组合起来构成的一个主码，一个关系模式只能有一个主码。
5. 应用规范化理论实现逻辑结构的优化
逻辑结构设计的结果是数据模型。以上主要介绍了如何将以E-R图表示的概念结构转化为以关系模型表示的逻辑结构。在形成关系模式后，还需要对其进行优化处理，以尽可能地减少数据冗余、删除冲突和插入冲突等问题。
6. 用户子模式的设计
用户子模式也称为外模式，它是面向用户的，是用户可见的数据模型部分。它可以屏蔽概念模式，有助于实现程序与数据的独立，可以满足不同用户对数据的个性化需求，同时也有利于数据库的管理。
用户子模式的设计主要是利用局部E-R图，因为每一张E-R图一般都是表示局部概念结构。现在流行的DBMS一般都提供了视图功能，支持用户的虚拟视图。我们可以利用这个功能设计符合不同局部应用需要的用户子模式。
3.3 物理结构设计
物理结构设计就是为既定的数据模型选取特定的、有效的存储结构和存储路径的过程。
特定性是指跟具体的计算机系统有关，包括操作系统和DBMS等；
有效性是指以尽可能少的系统资源获取数据库尽可能高的运行效率。
物理结构设计的内容主要包括数据库存储结构的确定和数据库存取方法的确定。
数据库存储结构的设计
任务：确定数据的存放位置和使用的存储结构，确定在磁盘空间中存储关系、索引、日志、备份等的数据库文件，设置系统存储参数，目的是使得以最小的系统资源获取最高的系统性能。
存储结构的设计是在已选定的DBMS和硬件条件下进行的，主要从以下两个方面考虑:
（1）确定数据的存放方式
在大多的关系DBMS中，数据的分类和指定存储是通过数据文件的划分和存储来实现。
在DBMS中，不能直接指定数据的存放位置，而只能通过一定的机制实现数据文件的指定存放，从而实现将数据存放在指定的位置。确定了数据文件的存放位置也就确定了数据的存放位置。
数据文件的划分和存储主要是基于数据访问的稳定性、安全性、效率等方面考虑的，相应的指导性规则包括：
数据库文件和日志文件应该分开存放在磁盘中。
如果计算机系统中有多个磁盘，可以将数据库文件分为多个文件，并分布在不同的磁盘中。
将数据表和索引等分开存放在不同的数据库文件中。
大的数据对象要分散存储在不同的数据库文件中。
（2）确定系统参数的配置
系统参数是指DBMS提供设置参数。这些参数主要包括数据库的大小、同时连接的用户数、缓冲区个数和大小、索引文件的大小、填充因子等。DBMS一般都对这些参数设置了初始值，但这些设置并不一定适应每一种应用环境，这需要设计人员重新设计。
这些参数的配置操作一般都可以在DBMS提供管理工具中完成。
【例子】 SQL Server 2008提供的管理工具是SQL Server Management Studio（SSMS），SSMS可以管理SQL Server 2008的所有组件，包括访问、配置、控制和开发这些组件。
2. 确定存取方法
存取方法即关系模式的存取方法，目的是实现数据的快速存取。每一种DBMS都提供了多种不同的存取方法，索引法是最常用的一种，在实际开发当中用得最多。以下重点介绍索引法。
索引为什么可以提高数据库中数据的存取速度呢？
这道理与目录可以提高书的查阅速度的道理一样，即可以将索引形象地比喻为目录。索引正是基于目录的原理来设计，它是“数据标题”和数据内存地址的列表。通过索引可以从部分数据检索中实现数据的快速查找，从而提高数据的查询效率。
索引的创建并不是无代价的。
索引本身也是一种数据表，同样占用存储资源，而且要保持与数据表的同步，这要求在进行数据更新操作（包括添加、删除和修改操作）时也要对索引进行相应的更新操作。如果索引很大时，其占用的空间资源以及对其更新维护所需要的代价同样是非常可观的。对索引的创建与否，应该慎重考虑。
在创建索引时，几个经验性的指导原则：
在经常用于检索的列上创建索引，特别是要对主码创建索引（一般是由DBMS自动完成）。
在外键上创建索引，因为它经常用于与其他关系进行连接查询。
多在以读为主或者经常需要排列的列上创建索引。因为索引已经排序，它可以加快读取速度和排序效率。
多在经常用于条件查询的列上创建索引，特别是对那些常常出现少量元组满足条件的列。
而对具有以下性质的列，则不宜对其创建索引：
对于不经常用于检索的列，则不宜在其上创建索引。
对于那些值域很小的列不应该创建索引。
对于值域严重分布不均匀的列不宜在其上创建索引。
对于更新操作非常频繁的列，不宜在其上创建索引。
对于长度超过30个字节的列，一般不要在其上创建索引。
4. 数据库实施
数据库实施包括以下几方面的内容：
1. 建立数据库结构
根据物理结构的设计结果，选定相应的DBMS。然后在该DBMS系统中利用其提供的DDL语言建立数据库结构。
例如，在SQL Server中，可用下列的SQL语句来分别创建数据库和数据表： CREATE DATABASE database_name
CREATE TABLE table_name
在数据库结构定义以后，通过DBMS提供的编译处理程序编译后即可形成了实际可运行的数据库。但这时的数据库还仅仅一个框架，内容是空的。要真正发挥它的作用，还需要编写相应的应用程序，将数据保存在其中，形成一个“有血有肉”的动态系统。
2. 装载测试数据，编写调试应用程序
应用程序设计与数据库设计可以同时进行，应用程序的代码编写和调试则在数据库结构创建以后进行的。
应用程序的编写和调试是一个反复进行的过程，其中需要对数据库进行测试性访问。这时应该在数据库中装载一些测试数据。这些数据可以随机产生，也可以用实际数据作为测试数据（但这些实际数据要留有副本）。
3. 试运行
在应用程序调试以后，给数据库加载一些实际数据并运行应用程序，但还没有正式投入使用，而只是想查看数据库应用系统各方面的功能，那么这种运行就称为试运行，试运行也称联合调试，
试运行与调试的区别：两者目的基本一样，但侧重点有所不同。调试主要是为了发现系统中可能存在的错误，以便及时纠正；试运行虽然也需要发现错误，但它更注重于系统性能的检测和评价。
试运行的主要工作包括：
系统性能检测。包括测试系统的稳定性、安全性和效率等方面的指标，查看是否符合设计时设定的目标。
系统功能检测。运行系统，按各个功能模块逐项检测，检查系统的各个功能模块是否能够完成既定的功能。
如果检测结果不符合设计目标，则返回相应的设计阶段，重新修改程序代码或数据库结构，直到满足要求为止。
5. 数据库系统的运行和维护
试运行结束并被证实符合设计要求后，数据库就可以正式投入使用。
数据库的正式使用标志着数据库开发阶段的基本结束，同时意味着数据库运行和维护阶段的开始。
数据库的运行和维护并不是数据库设计的终点，而是数据库设计的延续和提高。
数据库的日常运行和维护也是一项专业性很强的工作，需要很强的专业技术。维护工作不是普通的用户就能够胜任的，一般是由系统管理员（DBA）完成。这种工作就是软件产生品的售后服务。
在数据库的运行和维护阶段，DBA的主要工作包括：
1.数据库的转储和恢复
一旦数据库正式投入使用，企业的相关数据将全部存入数据库（一般不会另记在纸质材料中）。如果数据库发生故障，可能会导致这些数据的丢失，从而造成企业的重大损失。为了尽量避免在数据库发生故障时造成数据丢失，DBA应当根据应用的具体要求指定相应的备份和恢复方案，保证一旦发生故障，能够尽快将数据库恢复到某一种一致性的最近状态，尽量减少损失。
数据库转储：数据库恢复技术，是指定期地把整个数据库复制到磁盘或者其他存储设备上保护起来的过程。数据库的转储和恢复是数据库运行维护中最重要的工作之一。
2. 数据库性能的检测、分析和改善
随着运行时间的增加，数据库的物理存储不断发生改变，加上数据量和用户的不断增加，这都使得数据库的运行性能不断下降。DBA必须利用DBMS提供的性能监控和分析工具定期地对数据库的各种性能指标进行检测，以便及早地发现问题并采取相应的优化和改善措施。
3. 数据库的安全性和完整性维护
不管是从企业内部还是从企业外部来讲，数据库的安全性和完整性都是至关重要的。作为数据库的管理者，DBA必须对数据库的安全性和完整性负责。DBA应该认真审核每一个用户的身份，并正确授予相应的权限；随着时间的推移和应用环境的改变，对安全性的要求也随之发生变化，这要求DBA对数据库的安全性控制作出相应的调整，以适应新的情况。类似地，数据库的完整性约束条件也会发生变化，这同样要求DBA作出相应的修正，以满足新的要求。
4. 数据库的重组和重构
数据的插入、修改和删除是数据库的基本操作。这些操作的多次使用会使得数据在磁盘上的存储分布越来越散，导致数据的存储效率降低，整个系统性能下降。这时应该对数据库进行重新组织（即重组），以提高系统的性能。现在流行的DBMS一般都提供重组功能。
数据库的重构:对数据库的模式和内模式进行调整，如增加或删除某些列和表、增加或删除某些索引、修改数据库的完整性约束条件等，这种调整就是对数据库进行重新构造的过程。
数据库重组和数据库重构有着本质的区别：
数据库重组的目的：提高系统的性能，通过DBMS提供的功能对数据库在磁盘上的存储分布进行调整来达到重组的目的，重组不会改变数据库的模式和内模式；
数据库重构的目的：实现新的用户需求，需要修改数据库结构，从而使得数据库的概念模式和内模式也被修改。
不是在迫不得以的情况下，不要使用数据库重构。数据库重构不但使数据库结构发生了改变，而且在多数情况下也要求应用程序作出相应的修改。这会导致“牵一发而动全身”的后果，由数据库重构而引起的修改工作量是非常大的。
数据库重构并不是“无所不能”，数据库重构可以实现新的用户需求，但这种需求的变化幅度必须限制在一定的范围内。超过这个范围，数据库重构可能无法实现，也可能是实现的代价太高而失去重构的意义。
