设计 Flashcards
数据库设计
广义地讲，是数据库及其应用系统的设计，即设计整个的数据库应用系统。狭义地讲，是设计数据库本身，即设计数据库的各级模式并建立数据库，这是数据库应用系统设计的一部分。
（本书重点是讲狭义的数据库设计。）
设计一个好的数据库与设计一个好的数据库应用系统是密不可分的。一个好的数据库结构是应用系统的基础。特别在实际的系统开发项目中两者更是密切相关、并行进行的。
数据库应用系统
使用数据库的各类信息系统。
数据库设计的定义
对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
信息管理要求是指在数据库中应该存储和管理哪些数据对象；数据操作要求是指对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
数据库设计的目标
为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。
高效率的运行环境包括：数据库数据的存取效率、数据库存储空间的利用率、数据库系统运行管理的效率等都是高的。
数据库建设
数据库应用系统从设计、实施到运行与维护的全过程。
数据库建设的基本规律
数据库建设和一般的软件系统的设计、开发和运行与维护有许多相同之处，更有其自身的一些特点。
1。数据库建设的基本规律。＂三分技术，七分管理，十二分基础数据＂。数据库建设是硬件、软件和干件（技术与管理的界面）的结合。
在数据库建设中不仅涉及技术，还涉及管理。要建设好一个数据库应用系统，开发技术固然重要，但是相比之下则管理更加重要。这里的管理不仅包括数据库建设作为一个大型的工程项目本身的项目管理，而且包括该企业（即应用部门）的业务管理。
企业的业务管理更加复杂，也更重要，对数据库结构的设计有直接影响。因为数据库结构（即数据库模式）是对企业中业务部门的数据以及各个业务部门之间数据联系的描述和抽象。业务部门的数据以及各个业务部门之间数据联系是和各个部门的职能、整个企业的管理模式密切相关的。
一个企业数据库建设的过程是企业管理模式的改革和提高的过程。只有把企业的管理创新做好，才能实现技术创新，才能建设好一个数据库应用系统。
十二分基础数据则强调了数据的收集、整理、组织和不断更新是数据库建设中的重要环节。
基础数据的收集、入库是数据库建立初期工作量最大、最烦琐、最细致的工作。在以后数据库运行过程中更需要不断地把新的数据加到数据库中，使数据库成为一个＂活库＂，否则就成了＂死库＂。数据库一旦成了＂死库＂，系统也就失去了应用价值，原来的投资也就失败了。
2。从软件设计的角度来看，数据库设计应和应用系统设计相结合。也就是说，整个设计过程中要把数据库结构（数据）设计和行为（对数据的处理）设计密切结合起来。
数据库设计方法
大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求从事数据库设计的专业人员具备多方面的技术和知识。主要包括： 计算机的基础知识； 软件工程的原理和方法； 程序设计的方法和技巧； 数据库的基本知识； 数据库设计技术； 应用领域的知识。
数据库设计方法
早期数据库设计主要采用手工加经验相结合的方法。设计的质量往往与设计人员的经验与水平有直接的关系。数据库设计是一种技艺，缺乏科学理论和工程方法的支持，设计质量难以保证。常常是数据库运行一段时间后又不同程度地发现各种问题，需要进行修改甚至重新设计，增加了系统维护的代价。
为此，人们努力探索，提出了各种数据库设计方法。例如：
1。新奥尔良方法。把数据库设计分为若干阶段和步骤，并采用一些辅助手段实现每一过程。运用软件工程的思想，按一定的设计规程用工程化方法设计数据库。属于规范设计法。
规范设计法从本质上看仍然是手工设计方法，其基本思想是过程迭代和逐步求精。
2。基于E-R模型的数据库设计方法。用E-R模型来设计数据库的概念模型，是数据库概念设计阶段广泛采用的方法。
3。3NF（第三范式）的设计方法。用关系数据理论为指导来设计数据库的逻辑模型，是设计关系数据库时在逻辑阶段可以采用的一种有效方法。
4。ODL（Object Definition Language）方法。面向对象的数据库设计方法。用面向对象的概念和术语来说明数据库结构。可以描述面向对象数据库结构设计，可以直接转换为面向对象的数据库。
数据库设计工具
数据库设计工具已经实用化和产品化。
例如：Designer2000和PowerDesigner分别是ORACLE公司和SYBASE公司推出的数据库设计工具软件，这些工具软件可以辅助设计人员完成数据库设计过程中的很多任务，已经普遍地用于大型数据库设计之中。
数据库设计的阶段
需求分析；
概念结构设计；
逻辑结构设计；
物理结构设计；
数据库实施；
数据库运行和维护。
在数据库设计过程中，需求分析和概念设计可以独立于任何数据库管理系统进行。逻辑设计和物理设计与选用的DBMS密切相关。
数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员、应用开发人员、数据库管理员和用户代表。系统分析和数据库设计人员是数据库设计的核心人员，他们将自始至终参与数据库设计，他们的水平决定了数据库系统的质量。用户和数据库管理员在数据库设计中也是举足轻重的，他们主要参加需求分析和数据库的运行和维护，他们的积极参与（不仅仅是配合）不但能加速数据库设计，而且也是决定数据库设计质量的重要因素。应用开发人员（包括程序员和操作员）分别负责编制程序和准备软硬件环境，他们在系统实施阶段参与进来。
如果所设计的数据库应用系统比较复杂，还应该考虑是否使用数据库设计工具以及选用何种工具，以提高数据库设计质量并减少设计工作量。
设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述6个阶段的不断往复。
这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。
需求分析阶段
进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。
需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。需求分析是否做得充分与准确，决定了在其上构建数据库的速度与质量。需求分析做得不好，甚至会导致整个数据库设计返工重做。
简单地说就是分析用户的要求。是设计数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
概念结构设计阶段
是整个数据库设计的关键，通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。
物理结构设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
数据库实施阶段
设计人员运用DBMS提供的数据库语言（如SQL）、工具及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行客观的评价、调整与修改。
数据库设计过程中的各级模式
数据库设计的不同阶段形成数据库的各级模式。需求分析阶段，综合各个用户的应用需求。
在概念设计阶段形成独立于机器特点，独立于各个DBMS产品的概念模式，在本篇中就是E-R图。
在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式。
在物理设计阶段，根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。
需求分析的任务（设计目标）
通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
需求分析阶段所调查的内容
调查的重点是＂数据＂和＂处理＂，通过调查、收集与分析，获得用户对数据库如下要求：
1。信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。
2。处理要求。指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。
3。安全性与完整性要求。
确定用户的最终需求是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此往往不能准确地表达自己的需求，所提出的需求往往不断地变化。另一方面，设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。因此设计人员必须不断深入地与用户交流，才能逐步确定用户的实际需求。
需求分析的方法
进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。
调查用户需求的步骤
1。调查组织机构情况。包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。
2。调查各部门的业务活动情况。包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么，这是调查的重点。
3。在熟悉了业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求，这是调查的又一个重点。
4。确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
调查方法
1。跟班作业。通过亲身参加业务工作来了解业务活动的情况。
2。开调查会。通过与用户座谈来了解业务活动的情况及用户需求。
3。请专人介绍。
4。询问。对某些调查中的问题，可以找专人询问。
5。设计调查表请用户填写。如果调查表设计得合理，这种方法是很有效的。
6。查阅记录。查阅与原系统有关的数据记录。
做需求调查时，往往需要同时采用上述多种方法。但无论使用何种调查方法，都必须有用户的积极参与和配合。
调查了解了用户需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中，结构化分析（SA）是一种简单实用的方法。SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。SA方法把任何一个系统都抽象为（数据来源-（数据流）>处理-（数据流）>数据输出，处理数据存储）的形式。要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。
数据流图表达了数据和处理过程的关系。在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。系统中的数据则借助数据字典（DD）来描述。
对用户需求进行分析与表达后，必须提交给用户，征得用户的认可。
数据字典的内容
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分。
其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
数据字典
数据流图表达了数据和处理的关系，数据字典则是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典在数据库设计中占有很重要的地位。
数据项
数据项是不可再分的数据单位。
数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
其中，＂取值范围＂、＂与其他数据项的逻辑关系＂定义了数据的完整性约束条件，是设计数据检验功能的依据。
可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。即按实际语义，写出每个数据项之间的数据依赖，它们是数据库逻辑设计阶段数据模型优化的依据。
数据结构
反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
数据描述={数据结构名，含义说明，组成：{数据项或数据结构}}
数据流
数据流是数据结构在系统内传输的路径。
数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
其中，＂数据流来源＂是说明该数据流来自哪个过程；＂数据流去向＂是说明该数据流将到哪个过程去；＂平均流量＂是指在单位时间（每天、每周、每月等）里的传输次数；＂高峰期流量＂则是指在高峰时期的数据流量。
数据存储
数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或手工凭单，也可以是计算机文档。
数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
其中，＂存取频度＂指每小时或每天或每周存取几次、每次存取多少数据等信息；＂存取方式＂包括是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等；另外，＂输入的数据流＂要指出其来源；＂输出的数据流＂要指出其去向。
处理过程
处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。
处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
其中，＂简要说明＂中主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么（而不是怎么做），处理要求包括处理频度要求，如单位时间里处理多少事务、多少数据量，响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。
强调两点
1。需求分析阶段的一个重要而困难的任务是收集将来应用所涉及的数据，设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充。
2。必须强调用户的参与，这是数据库应用系统设计的特点。数据库应用系统和广泛的用户有密切的联系，许多人要使用数据库。数据库的设计和建立又可能对更多人的工作环境产生重要影响。因此用户的参与是数据库设计不可分割的一部分。在数据分析阶段，任何调查研究没有用户的积极参与是寸步难行的。设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果承担共同的责任。
数据字典的作用
数据字典是关于数据库中数据的一种描述，在需求分析阶段建立，是下一步进行概念设计的基础，并在数据库设计过程中不断修改、充实和完善。
明确地把需求收集和分析作为数据库设计的第一阶段是十分重要的。这一阶段收集到的基础数据（用数据字典来表达）和一组数据流程图（DFD）是下一步进行概念设计的基础。
概念结构设计
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。
概念结构的主要特点
1。能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求，是对现实世界的一个真实模型。
2。易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。
3。易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
4。易于向关系、网状、层次等各种数据模型转换。
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。
描述概念模型的有力工具是E-R模型。
数据库概念结构设计的重要性
数据库概念设计是整个数据库设计的关键，在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构（概念结构），以此作为各种数据模型的基础，才能更好地、更准确地用某一DBMS实现这些需求。
设计概念结构的方法
1。自顶向下。即首先定义全局概念结构的框架，然后逐步细化。
2。自底向上。即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。通常分两步：第一步是抽象数据并设计局部视图，第二步是集成局部视图，得到全局的概念结构。
3。逐步扩张。首先定义最重要的核心概念结构，然后向外扩充，以递进方式逐步生成其他概念结构，直至总体概念结构。
4。混合策略。即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
其中最常采用的策略是自底向上方法，即自顶向下地进行需求分析，然后再自底向上地设计概念结构。
数据抽象
概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。
一般有三种抽象
1。分类。定义某一类概念作为现实世界中一组对象的类型。这些对象具有某些共同的特性和行为。它抽象了对象值和型之间的＂is member of＂的语义。在E-R模型中，实体型就是这种抽象。
2。聚集。定义某一类型的组成成分。它抽象了对象内部类型和成分之间＂is part of＂的语义。在E-R模型中若干属性的聚集组成了实体型，就是这种抽象。更复杂的聚集即某一类型的成分仍是一个聚集。
3。概括。定义类型之间的一种子集联系。它抽象了类型之间的＂is subset of＂的语义。（吵类、子类）
原E-R模型中不具有概括，本书对E-R模型作了扩充，允许定义超类实体型和子类实体型。并用双竖边的矩形框表示子类，用直线加小圆圈表示超类-子类的联系。
概括有一个很重要的性质：继承性。子类继承超类上定义的所有抽象。子类可以增加自己的某些特殊属性。
概念结构设计的第一步
利用上面介绍的抽象机制对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性，标识实体的码，确定实体之间的联系类型（1:1，1:n，m:n），设计分E-R图。
具体做法是：
1。选择局部应用。根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点。让这组图中每一部分对应一个局部应用。由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据。
2。逐一设计分E-R图。选择好局部应用之后，就要对每个局部应用逐一设计分E-R图。在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。
事实上，在现实世界中具体的应环境常常对实体和属性已经作了大体的自然划分。在数据字典中，＂数据结构＂、＂数据流＂和＂数据存储＂都是若干属性有意义的聚合，就体现了这种划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。
在调整中遵循的一条原则是：为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
符合什么条件的事物可以作为属性对待呢？划分准则：
1。作为＂属性＂，不能再具有需要描述的性质。＂属性＂必须是不可分的数据项，不能包含其他属性。
2。＂属性＂不能与其他实体有联系，即E-R图中所表示的联系是实体之间的联系。
视图的集成的方式
各子系统的分E-R图设计好以后，下一步就是要将所有的分E-R图综合成一个系统的总E-R图。 视图集成可以有两种方式： 1。多个分E-R图一次集成。 2。逐步集成。用累加的方式一次集成两个分E-R图。 第一种方法比较复杂，做起来难度较大。 第二种方法每次只集成两个分E-R图，可以降低复杂度。
集成局部E-R图的步骤
无论采用哪种方式，每次集成局部E-R图时都需要分两步走：
1。合并。解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。
2。修改和重构。消除不必要的冗余，生成基本E-R图。
合并分E-R图，生成初步E-R图
各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部视图的设计，这就导致各个分E-R图之间必定会存在许多不一致的地方，称之为冲突。因此，合并分E-R图时并不能简单地将各个分E-R图画到一起，而是必须着力消除各个分E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各分E-R图的冲突是合并分E-R图的主要工作与关键所在。
各分E-R图之间的冲突
主要有三类：属性冲突、命名冲突和结构冲突。
属性冲突
1。属性域冲突，即属性值的类型、取值范围或取值集合不同。
2。属性取值单位冲突。
属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。
命名冲突
1。同名异义。即不同意义的对象在不同的局部应用中具有相同的名字。
2。异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。
命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，通过讨论、协商等行政手段加以解决。
结构冲突
1。同一对象在不同应用中具有不同的抽象。
解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。
2。同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同。
这是很常见的一种冲突，原因是不同的局部应用关心的是该实体的不同侧面。解决方法是使该实体的属性取各分E-R图中属性的并集，再适当调整属性的次序。
3。实体间的联系在不同的分E-R图中为不同的类型。（一对一或一对多，两个实体发生联系或三个实体发生联系）
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
消除不必要的冗余，设计基本E-R图
在初步E-R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
消除冗余的方法
1。主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。
2。除分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具。具体方法如下：
1）确定分E-R图实体之间的数据依赖。实体间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。
2）求函数依赖集FL的最小覆盖GL，差集为D=FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。
由于规范化理论受到泛关系假设的限制，应注意下面两个问题：
1，冗余的联系一定在D中，而D中的联系不一定是冗余的。
2，当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。
数据库概念结构设计的步骤
概念结构的设计方法有多种，其中最经常采用的策略是自底向上方法，该方法的设计通常分为两个步骤：
1。抽象数据并设计局部视图。
2。集成局部视图，得到全局的概念结构。
数据库概念结构设计的重要性
数据库概念设计是整个数据库设计的关键，在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构（概念结构），以此作为各种数据模型的基础，才能更好地、更准确地用某一DBMS实现这些需求。
逻辑结构设计
概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
从理论上讲，设计逻辑结构应该选择最适于相应概念结构的数据模型，然后对支持这种数据模型的各种DBMS进行比较，从中选出最合适的DBMS。但实际情况往往是已给定了某种DBMS，设计人员没有选择的余地。目前DBMS产品一般支持关系、网状、层次三种模型中的某一种。
设计逻辑结构的步骤
1。将概念结构转换为一般的关系、网状、层次模型。
2。将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。
3。对数据模型进行优化。
为什么要视图集成
在对数据库系统进行概念结构设计时，一般采用自底向上的设计方法，把繁杂的大系统分解为子系统。首先设计各个子系统的局部视图，然后通过视图集成的方式将各个子系统有机融合起来，综合成一个系统的总视图。这样设计思路清晰，由简到繁。由于数据库系统是从整体角度来看待和描述数据，因此数据不再面向某个具体应用而是整个系统。因此必须进行视图的集成，使得数据库能够被全系统的多个用户、多个应用所共享和使用。
E-R图向关系模型的转换要解决的问题
如何将实体型的实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
E-R图向关系模型的转换遵循的原则
一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
E-R图的三要素
实体型、实体的属性和实体型之间的联系。
一个1:1联系
可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
一个1:n联系
可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
一个m:n联系
一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
3个或3个以上实体间的一个多元联系
可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
E-R图向关系模型的转换
关系模型的逻辑结构是一组关系模式的集合。将E-R图转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。
形成了一般的数据模型后，下一步就是向特定的RDBMS的模型转换。对于目前大都RDBMS来说，一般不必转换。
数据模型优化的方法
1。确定数据依赖。用数据依赖的概念分析和表示数据项之间的联系，写出每个数据项之间的数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。
2。对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
3。按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
4。按照需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解。
并不是规范化程度越高的关系就越优。对于一个具体应用来说，到底规范化到什么程度，需要权衡响应时间和潜在问题两者的利弊决定。
5。对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。
水平分解
把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。根据＂80/20原则＂，一个大关系中，经常被使用的数据只是关系的一部分，约20%，可以把经常使用的数据分解出来，形成一个子关系。如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。
垂直分解
把关系模式R的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是，经常在一起使用的属性从R中分解出来形成一个子关系模式。垂直分解可以提高某些事务的效率，但也可能使另一些事务不得不执行连接操作，从而降低了效率。因此是否进行垂直分解取决于分解后R上的所有事务的总效率是否得到了提高。垂直分解需要确保无损连接性和保持函数依赖，即保证分解后的关系具有无损连接性和保持函数依赖性。
设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。
目前关系数据库管理系统一般都提供了视图概念，可以利用这一功能设计更符合局部用户需要的用户外模式。
定义数据库全局逻辑模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便。包括：
1。使用更符合用户习惯的别名。在合并分E-R图时，曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。用View机制可以在设计用户View时重新定义某些属性名，使其与用户习惯一致，以方便使用。
2。可以对不同级别的用户定义不同的View，以保证系统的安全性。防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。
3。简化用户对系统的使用。如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，大大简化了用户的使用。
数据库的物理结构
数据库在物理设备上的存储结构与存取方法。
它依赖于选定的数据库管理系统。
数据库的物理设计
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程。
数据库的物理设计的步骤
1。确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。
2。对物理结构进行评价，评价的重点是时间和空间效率。
如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
数据库物理设计的内容和方法
不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。希望设计优化的物理数据库结构，使得在数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大。为此，首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数。其次，要充分了解所用RDBMS的内部特征，特别是系统提供的存取方法和存储结构。
对于数据库查询事务，需要得到的信息
1。查询的关系。
2。查询条件所涉及的属性。
3。连接条件所涉及的属性。
4。查询的投影属性。
对于数据更新事务，需要得到的信息
1。被更新的关系。
2。每个关系上的更新操作条件所涉及的属性。
3。修改操作要改变的属性值。
具有相同码的关系模式
可以合并。
规范化理论对数据库设计有什么指导意义
规范化理论为数据库设计人员判断关系模式优劣提供了理论标准，可用来预测模式可能出现的问题，使数据库设计工作有了严格的理论基础。
数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。
关系数据模型的优化通常以规范化理论为指导。
聚簇
为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块。
设计候选聚簇
1。对经常在一起进行连接操作的关系可以建立聚簇。
2。如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可以建立聚簇。
3。如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可以建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少了，聚簇的效果不明显。
然后检查候选聚簇中的关系，取消其中不必要的关系。
1。从聚簇中删除经常进行全表扫描的关系。
2。从聚簇中删除更新操作远多于连接操作的关系。
3。不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。
聚簇的注意
聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建。当一个元组的聚簇码值改变时，该元组的存储位置也要做相应移动，聚簇码值要相对稳定，以减少修改聚簇码值所引起的维护开销。
因此，当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的，这时可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY、GROUP BY、UNION、DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作；否则很可能会适得其反。
信息
还需要知道每个事务在各关系上运行的频率和性能要求。
上述这些信息是确定关系的存取方法的依据。
数据库上运行的事务会不断变化、增加或减少，以后要根据上述设计信息的变化调整数据库的物理结构。
HASH存取方法的选择
规则：
如果一个关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中，而且满足下列两个条件之一，则此关系可以选择HASH存取方法：
1。如果一个关系的大小可预知，而且不变。
2。如果关系的大小动态改变，而且数据库管理系统提供了动态HASH存取方法。
确定数据库的物理结构
确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。这3个方面常常是互相矛盾的，因此需要进行权衡，选择一个折中方案。
确定数据的存放位置
为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。
例如，目前许多计算机有多个磁盘或磁盘阵列，因此可以将表和索引放在不同的磁盘上，在查询时，由于磁盘驱动器并行工作，可以提高物理I/O读写的效率；也可以将比较大的表分放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效；还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘上，以改进系统性能。
由于各个系统所能提供的对数据进行物理安排的手段、方法差异很大，因此设计人员应仔细了解给定的RDBMS提供的方法和参数，针对应用环境的要求，对数据进行适当的物理安排。
确定系统配置
DBMS产品一般都提供了一些系统配置变量、存储分配参数，供设计人员和DBA对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的默认值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值，以改善系统的性能。
系统配置变量很多，例如：同时使用数据库的用户数，同时打开的数据库对象数，内存分配参数，缓冲区分配参数（使用的缓冲区长度、个数），存储分配参数，物理块的大小，物理块装填因子，时间片大小，数据库的大小，锁的数目等。这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最佳。
在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
关系数据库物理设计的内容主要包括
1。为关系模式选择存取方法。
2。设计关系、索引等数据库文件的物理存储结构。
评价物理结构
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
数据库的实施和维护
完成数据库的物理设计之后，设计人员就要用RDBMS提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为DBMS可以接受的源代码，再经过调试产生目标模式。然后就可以组织数据入库了，这就是数据库实施阶段。
数据输入在实施阶段的重要性
数据库是用来对数据进行存储、管理与应用的，因此在实施阶段必须将原有系统中的历史数据输入数据库中。一般数据库系统中，数据量都很大，而且数据来源于部门中的各个不同的单位，数据的组织方式、结构和格式都与新设计的数据库系统有相当的差距。组织数据录入就要将各类数据源数据从各个局部应用中抽取出来，输入计算机，再分类转换，最后综合成符合新设计的数据库结构的形式，输入数据库。因此这样的数据转换、组织入库的工作是相当费力、费时的。
特别是原系统是手工数据处理系统时，各类数据分散在各种不同的原始表格、凭证、单据之中。在向新的数据库系统中输入数据时，还要处理大量的纸质文件，工作量就更大。
E-R图向关系模型的转换要解决的问题
如何将实体型的实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
数据库的试运行
在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试，这又称为数据库的试运行。
这有阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，对应用程序部分则要修改、调整，直到达到设计要求为止。
在数据库试运行时，还要测试系统的性能指标，分析其是否达到设计目标。在对数据库进行物理设计时已初步确定了系统的物理参数值，但一般的情况下，设计时的考虑在许多方面只是近似的估计，和实际系统运行总有一定的差距，因此必须在试运行阶段实际测量和评价系统性能指标。事实上，有些参数的最佳值往往是经过运行调试后找到的。如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段，修改逻辑结构。
数据库的重组织和重构造
在重组织的过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针等，提高系统性能。
数据库的重组织并不修改原设计的逻辑和物理结构，而数据库的重构造则不同，它是指部分修改数据库的模式和内模式。
保证输入数据正确性的方法
为提高数据输入工作的效率和质量，应该针对具体的应用环境设计一个数据录入子系统，由计算机来完成数据入库的任务。在源数据入库之前要采用多种方法对它们进行检验，以防止不正确的数据入库，这部分的工作在整个数据输入子系统再是非常重要的。
现有的RDBMS一般都提供不同RDBMS之间数据转换的工具，若原来是数据库系统，就要充分利用新系统的数据转换工具。
数据库应用程序的设计应该与数据库设计同时进行，因此在组织数据入库的同时还要调试应用程序。
E-R图向关系模型的转换遵循的原则
一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
数据库试运行的注意
1。组织数据入库是十分费时、费力的事，如果试运行后还要修改数据库的设计，还要重新组织数据入库。因此应分期分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后，再大批量输入数据，逐步增加数据量，逐步完成运行评价。
2。在数据库试运行阶段，由于系统还不稳定，硬、软件故障随时都可能发生。而系统的操作人员对新系统还不熟悉，误操作也不可避免，因此应首先调试运行DBMS的恢复功能，做好数据库的转储和恢复工作。一旦故障发生，能使数据库尽快恢复，尽量减少对数据库的破坏。
数据库实施阶段包括两项重要的工作
1。数据的载入。
2。应用程序的编码和调试。
进行数据库重组织和重构造的原因
数据库运行一段时间后，由于纪录不断增、删、改，会使数据库的物理存储情况变坏，降低了数据的存取效率，数据库性能下降，这时DBA就要对数据库进行重组织或部分重组织（只对频繁增、删的表进行重组织）。DBMS一般都提供数据重组织用的实用程序。
数据库的运行和维护
数据库试运行合格后，数据库开发工作就基本完成，即可投入正式运行了。但是，由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。
E-R图向关系模型的转换
关系模型的逻辑结构是一组关系模式的集合。将E-R图转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。
形成了一般的数据模型后，下一步就是向特定的RDBMS的模型转换。对于目前大都RDBMS来说，一般不必转换。
在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，它包括：
1。数据库的转储和恢复。是系统正式运行后最重要的维护工作之一。DBA要针对不同的应用要求制定不同的转储计划，以保证一旦发生故障能尽快将数据库恢复到某种一致的状态，并尽可能减少对数据库的破坏。
2。数据库的安全性、完整性控制。在数据库运行过程中，由于应用环境的变化，对安全性的要求也会发生变化，比如有的数据原来是机密的，现在可以是公开查询的了，而新加入的数据又可能是机密的了。系统中用户的密级也会改变。这些都需要DBA根据实际情况修改原有的安全性控制。同样，数据库的完整性约束条件也会变化，也需要DBA不断修正，以满足用户要求。
3。数据库性能的监督、分析和改造。在数据库运行过程中，监督系统运行，对监测数据进行分析，找出改进系统性能的方法是DBA的又一重要任务。目前有些DBMS产品提供了监测系统性能参数的工具，DBA可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。DBA应仔细分析这些数据，判断当前系统运行状况是否是最佳，应当做哪些改进，例如调整系统物理参数或对数据库进行重组织或重构造等。
4。数据库的重组织与重构造。由于数据库应用环境发生变化，增加了新的应用或新的实体，取消了某些应用，有的实体与实体间的联系也发生了变化等，使原有的数据库设计不能满足新的需求，需要调整数据库的模式和内模式。例如，在表中增加或删除某些数据项，改变数据项的类型，增加或删除某个表，改变数据库的容量，增加或删除某些索引等。当然数据库的重构也是有限的，只能做部分修改。如果应用变化太大，重构也无济于事，说明此数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统了。
关系数据库物理设计的内容主要包括
1。为关系模式选择存取方法。
2。设计关系、索引等数据库文件的物理存储结构。
聚簇
为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块。
设计候选聚簇
1。对经常在一起进行连接操作的关系可以建立聚簇。
2。如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可以建立聚簇。
3。如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可以建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少了，聚簇的效果不明显。
然后检查候选聚簇中的关系，取消其中不必要的关系。
1。从聚簇中删除经常进行全表扫描的关系。
2。从聚簇中删除更新操作远多于连接操作的关系。
3。不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。
聚簇的注意
聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建。当一个元组的聚簇码值改变时，该元组的存储位置也要做相应移动，聚簇码值要相对稳定，以减少修改聚簇码值所引起的维护开销。
因此，当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的，这时可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY、GROUP BY、UNION、DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作；否则很可能会适得其反。
HASH存取方法的选择
规则：
如果一个关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中，而且满足下列两个条件之一，则此关系可以选择HASH存取方法：
1。如果一个关系的大小可预知，而且不变。
2。如果关系的大小动态改变，而且数据库管理系统提供了动态HASH存取方法。
数据库物理设计的内容和方法
不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。希望设计优化的物理数据库结构，使得在数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大。为此，首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数。其次，要充分了解所用RDBMS的内部特征，特别是系统提供的存取方法和存储结构。
对于数据库查询事务，需要得到的信息
1。查询的关系。
2。查询条件所涉及的属性。
3。连接条件所涉及的属性。
4。查询的投影属性。
对于数据更新事务，需要得到的信息
1。被更新的关系。
2。每个关系上的更新操作条件所涉及的属性。
3。修改操作要改变的属性值。
信息
还需要知道每个事务在各关系上运行的频率和性能要求。
上述这些信息是确定关系的存取方法的依据。
数据库上运行的事务会不断变化、增加或减少，以后要根据上述设计信息的变化调整数据库的物理结构。
索引存取方法的选择
根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些属性列要设计为唯一索引等。
1。如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。
2。如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
3。如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。
关系上定义的索引数并不是越多越好，系统为维护索引要付出代价，查找索引也要付出代价。例如，若一个关系的更新频率很高，这个关系上定义的索引数不能太多。因为更新一个关系时，必须对这个关系上有关的索引做相应的修改。
存取方法
存取方法是快速存取数据库中数据的技术。数据库管理系统一般都提供多种存取方法。
常用的存取方法有三类。第一类是索引方法，目前主要是B+树索引方法；第二类是聚簇方法；第三类是HASH方法。
B+树索引方法是数据库中经典的存取方法，使用最普遍。
聚簇存取方法的选择
聚簇功能可以大大提高按聚簇码进行查询的效率。
聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系。即把多个连接关系的元组按连接属性值聚集存放，聚簇中的连接属性称为聚簇码。这就相当于把多个关系按＂预连接＂的形式存放，从而大大提高连接操作的效率。
一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。
选择聚簇存取方法，即确定要建立多少个聚簇，每个聚簇中包括哪些关系。
关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径。
存取方法
存取方法是快速存取数据库中数据的技术。数据库管理系统一般都提供多种存取方法。
常用的存取方法有三类。第一类是索引方法，目前主要是B+树索引方法；第二类是聚簇方法；第三类是HASH方法。
B+树索引方法是数据库中经典的存取方法，使用最普遍。
确定数据库的物理结构
确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。这3个方面常常是互相矛盾的，因此需要进行权衡，选择一个折中方案。
确定数据的存放位置
为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。
例如，目前许多计算机有多个磁盘或磁盘阵列，因此可以将表和索引放在不同的磁盘上，在查询时，由于磁盘驱动器并行工作，可以提高物理I/O读写的效率；也可以将比较大的表分放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效；还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘上，以改进系统性能。
由于各个系统所能提供的对数据进行物理安排的手段、方法差异很大，因此设计人员应仔细了解给定的RDBMS提供的方法和参数，针对应用环境的要求，对数据进行适当的物理安排。
确定系统配置
DBMS产品一般都提供了一些系统配置变量、存储分配参数，供设计人员和DBA对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的默认值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值，以改善系统的性能。
系统配置变量很多，例如：同时使用数据库的用户数，同时打开的数据库对象数，内存分配参数，缓冲区分配参数（使用的缓冲区长度、个数），存储分配参数，物理块的大小，物理块装填因子，时间片大小，数据库的大小，锁的数目等。这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最佳。
在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
评价物理结构
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
数据库的实施和维护
完成数据库的物理设计之后，设计人员就要用RDBMS提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为DBMS可以接受的源代码，再经过调试产生目标模式。然后就可以组织数据入库了，这就是数据库实施阶段。
数据库实施阶段包括两项重要的工作
1。数据的载入。
2。应用程序的编码和调试。
一般数据库系统中，数据量都很大，而且数据来源于部门中的各个不同的单位，数据的组织方式、结构和格式都与新设计的数据库系统有相当的差距。组织数据录入就要将各类数据源数据从各个局部应用中抽取出来，输入计算机，再分类转换，最后综合成符合新设计的数据库结构的形式，输入数据库。因此这样的数据转换、组织入库的工作是相当费力、费时的。
特别是原系统是手工数据处理系统时，各类数据分散在各种不同的原始表格、凭证、单据之中。在向新的数据库系统中输入数据时，还要处理大量的纸质文件，工作量就更大。
为提高数据输入工作的效率和质量，应该针对具体的应用环境设计一个数据录入子系统，由计算机来完成数据入库的任务。在源数据入库之前要采用多种方法对它们进行检验，以防止不正确的数据入库，这部分的工作在整个数据输入子系统再是非常重要的。
现有的RDBMS一般都提供不同RDBMS之间数据转换的工具，若原来是数据库系统，就要充分利用新系统的数据转换工具。
数据库应用程序的设计应该与数据库设计同时进行，因此在组织数据入库的同时还要调试应用程序。
数据库的试运行
在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试，这又称为数据库的试运行。
这有阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，对应用程序部分则要修改、调整，直到达到设计要求为止。
在数据库试运行时，还要测试系统的性能指标，分析其是否达到设计目标。在对数据库进行物理设计时已初步确定了系统的物理参数值，但一般的情况下，设计时的考虑在许多方面只是近似的估计，和实际系统运行总有一定的差距，因此必须在试运行阶段实际测量和评价系统性能指标。事实上，有些参数的最佳值往往是经过运行调试后找到的。如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段，修改逻辑结构。
数据库试运行的注意
1。组织数据入库是十分费时、费力的事，如果试运行后还要修改数据库的设计，还要重新组织数据入库。因此应分期分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后，再大批量输入数据，逐步增加数据量，逐步完成运行评价。
2。在数据库试运行阶段，由于系统还不稳定，硬、软件故障随时都可能发生。而系统的操作人员对新系统还不熟悉，误操作也不可避免，因此应首先调试运行DBMS的恢复功能，做好数据库的转储和恢复工作。一旦故障发生，能使数据库尽快恢复，尽量减少对数据库的破坏。
数据库的运行和维护
数据库试运行合格后，数据库开发工作就基本完成，即可投入正式运行了。但是，由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。
在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，它包括：
1。数据库的转储和恢复。是系统正式运行后最重要的维护工作之一。DBA要针对不同的应用要求制定不同的转储计划，以保证一旦发生故障能尽快将数据库恢复到某种一致的状态，并尽可能减少对数据库的破坏。
2。数据库的安全性、完整性控制。在数据库运行过程中，由于应用环境的变化，对安全性的要求也会发生变化，比如有的数据原来是机密的，现在可以是公开查询的了，而新加入的数据又可能是机密的了。系统中用户的密级也会改变。这些都需要DBA根据实际情况修改原有的安全性控制。同样，数据库的完整性约束条件也会变化，也需要DBA不断修正，以满足用户要求。
3。数据库性能的监督、分析和改造。在数据库运行过程中，监督系统运行，对监测数据进行分析，找出改进系统性能的方法是DBA的又一重要任务。目前有些DBMS产品提供了监测系统性能参数的工具，DBA可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。DBA应仔细分析这些数据，判断当前系统运行状况是否是最佳，应当做哪些改进，例如调整系统物理参数或对数据库进行重组织或重构造等。
4。数据库的重组织与重构造。数据库运行一段时间后，由于纪录不断增、删、改，会使数据库的物理存储情况变坏，降低了数据的存取效率，数据库性能下降，这时DBA就要对数据库进行重组织或部分重组织（只对频繁增、删的表进行重组织）。DBMS一般都提供数据重组织用的实用程序。在重组织的过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针等，提高系统性能。
数据库的重组织并不修改原设计的逻辑和物理结构，而数据库的重构造则不同，它是指部分修改数据库的模式和内模式。
由于数据库应用环境发生变化，增加了新的应用或新的实体，取消了某些应用，有的实体与实体间的联系也发生了变化等，使原有的数据库设计不能满足新的需求，需要调整数据库的模式和内模式。例如，在表中增加或删除某些数据项，改变数据项的类型，增加或删除某个表，改变数据库的容量，增加或删除某些索引等。当然数据库的重构也是有限的，只能做部分修改。如果应用变化太大，重构也无济于事，说明此数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统了。
关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径。
索引存取方法的选择
根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些属性列要设计为唯一索引等。
1。如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。
2。如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
3。如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。
关系上定义的索引数并不是越多越好，系统为维护索引要付出代价，查找索引也要付出代价。例如，若一个关系的更新频率很高，这个关系上定义的索引数不能太多。因为更新一个关系时，必须对这个关系上有关的索引做相应的修改。
聚簇存取方法的选择
聚簇功能可以大大提高按聚簇码进行查询的效率。
聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系。即把多个连接关系的元组按连接属性值聚集存放，聚簇中的连接属性称为聚簇码。这就相当于把多个关系按＂预连接＂的形式存放，从而大大提高连接操作的效率。
一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。
选择聚簇存取方法，即确定要建立多少个聚簇，每个聚簇中包括哪些关系。
