数据库原理与开发技术 课件 第5章 数据库设计

第5章数据库设计本章主要内容：（1）数据库设计概述：概念、目标、方法和原则，及设计的一般步骤（2）需求分析：组织机构图、业务流程图、系统功能图、数据流程图（3）概念设计：局部E-R模型、全局E-R模型、评审（4）逻辑设计：将E-R模型转为关系模型的规则、关系模型的优化（5）物理设计：确定数据库的物理结构、评价数据库的物理结构（6）数据库实现、运行和维护5.1数据库设计概述在数据库领域，一般把使用了数据库的信息系统称为数据库应用系统。例如银行、保险、电商、办公自动化等管理系统。开发一个好的数据库应用系统，其核心是要设计一个好的数据库，其性能主要表现在：（1）数据访问效率高。

（2）能减少数据冗余，节省存储空间，便于系统进一步扩展。

（3）可以使应用程序的开发变得容易。5.1.1数据库设计的概念、目标、方法和原则1.什么是数据库设计数据库设计是指对于一个给定的应用环境，设计一个优化的数据库逻辑模式和数据物理结构，建立数据库及应用系统，使之能够有效地存储和管理数据，以满足用户对数据的各种查询要求和处理要求。

2.数据库设计的目标数据库设计有两大目标，一是满足用户对系统的应用功能需求，二是数据库具有良好的性能。5.1.1数据库设计的概念、目标、方法和原则

满足用户的应用功能需求，主要是指把用户当前的应用需求，以及可预知的潜在的应用需求所需要的数据及其联系，全部准确地存储在数据库中，并根据用户的实际环境条件，满足用户对数据的插入、修改、删除及查询等操作。

良好的数据库性能，是指设计的数据库应具有良好的存储结构，保证数据的完整性、一致性和安全性等要求。5.1.1数据库设计的概念、目标、方法和原则3.数据库设计的方法大型数据库的设计是一个系统工程，它要求从业人员要具备多方面的学科知识和计算机技术，丰富的行业经验。具体说来，主要包括：

1）计算机的基础知识，包括：计算机应用原理、操作系统、计算机网络技术。2）软件工程的开发原理和方法。3）程序设计的方法和经验积累。4）数据库的基础知识。5）数据库设计的技术和经验。6）应用领域的行业知识。5.1.1数据库设计的概念、目标、方法和原则随着开发经验的积累和行业的规范，人们开始运用软件工程的思想，并提出了各种准则，来规范数据库设计。目前常用的规范设计方法有：（1）新奥尔良法。1978年10月来自欧美国家的主要数据库专家在美国的新奥尔良市讨论数据库设计问题，并提出了相应的工作规范。该方法将数据设计分为：需求分析、概念设计、逻辑设计和物理设计四个阶段。

（2）基于E-R模型的设计方法。

（3）第三范式（3NF）设计方法。

（4）统一建模语言（UnifiedModelLanguage，UML）方法。数据库工作者一直在努力研究和开发数据库设计工具，以提高工作效率。目前常用的数据库设计工具软件有：MSVisio、PowerDesigner等。5.1.1数据库设计的概念、目标、方法和原则4.数据库设计的一些原则

（1）索引（Index）的使用原则在表上创建索引一般有两个目的，一是维护索引列上取值的唯一性，二是加快表中数据的访问速度。操纵基本表中的数据，对应于索引列上的数据在物理上会进行同步维护，即索引会降低数据的插入、修改、删除的速度。因此索引会增加表维护的负担，设计时需要考虑两者之间的平衡。大型数据库有两种索引：簇索引和非簇索引。一个没有簇索引的表是按堆结构存储数据的，所有的数据均添加在表的尾部。而有簇索引的表，其数据在物理上会按照簇索引键的顺序存储。一个表只允许有一个簇索引，根据B树的结构，添加任何一种索引均可提高按索引列查询的速度，但会降低数据插入、修改、删除的性能。5.1.1数据库设计的概念、目标、方法和原则（2）数据的一致性和完整性为了保证数据库的一致性和完整性，减少数据冗余，设计时往往会通过主外键增加表间关联（Relation）。表间关联是一种强制性措施，它对父表和子表的插入、修改、删除操作均要占用系统的开销。同时，表间关联也会额外增加表间数据连接的查询操作负担。另外，最好不要用Identity属性字段作为主键与子表进行关联。实践中，为了提高系统的响应时间，合理的数据冗余是必要的。使用规则（Rule）和约束（Check）来防止用户对系统的误输入，是设计时常用的另一种手段。在验证数据的有效性方面，约束比规则要快。所有这些，在设计时，都应根据操作系统的类型、数据的访问频率和数据量的大小，加以均衡考虑。5.1.1数据库设计的概念、目标、方法和原则（3）正确理解范式，并合理遵循范式第一范式（1NF）是对属性的原子性约束，要求属性具有原子性，不可再分解；第二范式（2NF）是对元组的唯一性约束，要求元组有唯一性；第三范式（3NF）是对属性冗余的约束，即任何属性不能由其他属性派生出来。没有冗余的数据库设计时是可以做到的。但是，没有冗余的数据库不一定是最好的数据库。有时为了提高运行效率，可以降低范式标准，适当保留数据冗余。例如，在概念模型设计时严格遵守第三范式，其他范式的要求可以在物理模型设计时再考虑。5.1.1数据库设计的概念、目标、方法和原则（4）数据类型的选择

合理的数据类型选择对数据库的性能和操作具有很大的影响，尤其是数据量大、频繁访问的属性列。例如，定长字符和可变长字符，前者可提高数据访问速度，但会浪费存储空间，后者正好相反。

Text和Image字段属于指针型数据，主要用来存放二进制大型对象（Blob）。这类数据的操作比其他类型数据要慢，设计时要避开使用。但在存储二进制海量数据时，又有很大的优势。5.1.1数据库设计的概念、目标、方法和原则（5）信息隐藏原则为了提高数据库的安全性，可以利用DBMS的触发器、存储过程、函数等，把数据库中无法简化的复杂表关系封装到黑盒子中去，隐藏起来。

结构设计是指数据库的模式结构设计，包括概念结构、逻辑结构和物理结构。行为设计是指应用程序设计，包括功能组织、流程控制等方面的设计。（6）结构设计与行为设计相分离

在传统的软件工程中，比较注重处理过程的设计，不太注重数据结构的设计。数据库设计刚好相反，它的主要精力放在数据结构的设计上，例如基本表的结构、视图、索引等。5.1.2数据库系统的生存期仿照软件的生存期，把数据库系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间，称为数据库系统的生命周期或生存期。这个生存期一般划分为下面7个阶段：

1.系统规划对于大型数据库系统或大型信息系统的数据库群，规划阶段是非常必要的。规划的好坏直接影响到系统的成败。这个阶段具体可分为3个步骤：5.1.2数据库系统的生存期

1）系统调查。对需求方进行全面调查，发现其存在的主要问题。2）可行性分析。根据发现的问题，从技术、经济、效益等方面进行可行性分析，写出可行性分析研究报告，并组织专家进行讨论。3）确定数据库系统的总目标，对需求单位的工作流程进行优化，制定项目开发计划，最后形成“项目可行性研究报告”。

2.需求分析

数据库设计人员与需求方用户进行全方位沟通，收集数据库所有用户的信息内容和处理要求。在分析用户要求时，要确保用户目标的一致性。5.1.2数据库系统的生存期

3.概念设计

4.逻辑设计这个阶段将概念结构转为某个DBMS所能支持的数据模型，并对其进行优化，例如数据库模式的规范化。把需求分析阶段获得的用户信息要求，通过用户能够明白的语言，统一规划到一个整体的逻辑结构中，形成一个整体的概念模型，它独立于具体的DBMS和硬件。5.1.2数据库系统的生存期

5.物理设计6.系统实现根据物理设计的结果产生一个具体的数据库和应用程序，并把初始数据装入数据库中。这个阶段主要是为逻辑数据结构模型选取一个最适合应用环境的数据物理结构（包括存储结构和存取方法）。7.系统运行和维护收集、记录系统运行的情况，并根据用户的需求变化，对数据库结构进行修改或扩展。5.1.2数据库系统的生存期数据库应用系统的开发是一项高风险、高回报的系统工程。它需要调动双方（开发商、需求方）各方面的资源、相互配合才能推动项目的进程。一旦系统开发商和需求方（即用户）签订了开发协议，开发商应立即成立一个专业的以系统分析员为组长的项目开发小组，并要求需求方配备精通自身行业领域知识的人员，全程协助项目的开发。对于一般的数据库应用系统而言，数据库设计可以不包括系统规划阶段。具体的数据库设计步骤，主要按照后面6个阶段展开。在项目的整个开发期内，有两个非常重要的磨合期（也称危险期），如果双方处理得不好，会严重影响项目的进度，甚至成败。一个是需求分析阶段，另一个是系统试运行阶段。5.2需求分析本章主要内容：（1）数据库设计概述：概念、目标、方法和原则，及设计的一般步骤（2）需求分析：组织机构图、业务流程图、系统功能图、数据流程图（3）概念设计：局部E-R模型、全局E-R模型、评审（4）逻辑设计：将E-R模型转为关系模型的规则、关系模型的优化（5）物理设计：确定数据库的物理结构、评价数据库的物理结构（6）数据库实现、运行和维护5.2需求分析这一阶段是计算机开发人员和用户双方共同收集数据库所需要的信息内容和用户对处理的需求，并以需求说明书的形式确定下来，作为下一阶段系统开发的指南和项目验收的依据。

这是最费时、最复杂的一步，也是最重要的一步。一方面，数据库设计人员不熟悉用户行业的领域知识。另一方面，用户又不清楚计算机领域专业知识，不知如何向计算机人员清晰表达自己的信息需求。这个痛苦的磨合期，需要开发人员具备丰富的开发经验，驾驭分析方向，引导用户准确说出自己的业务需求。5.2需求分析开发人员必须高度重视系统的需求分析工作。因为需求分析的内容是否准确反映了用户的实际需求，将直接影响到后面各个阶段的设计工作。一点点偏差，都会导致整个数据库设计返工。5.2.1需求分析的工作步骤具体说来，需求分析的工作主要由下面4步组成：1.分析用户活动，产生业务流程图了解用户的组织机构图、各部门职能、业务活动流程，分析之后画出用户的业务流程图。5.2.1需求分析的工作步骤分析人员刚开始向用户了解需求分析时，先了解大概的框架，不要向用户询问每个业务具体细节。例如，以我国企业为例，一般企业（或公司）的组织结构，如图所示。我国企业组织机构图及关键岗位：销售管理业务流程图：5.2.1需求分析的工作步骤

2.确定系统范围，产生系统功能图这一步是确定系统的范围。在和用户经过充分讨论的基础上，明确用户业务活动中，哪些工作由计算机系统来做，哪些由人工来做，对用户的数据需求，以一个个具体的功能确定下来，画出系统功能图。这个功能就是人机界面，一个界面完成一个功能。5.2.1需求分析的工作步骤

2.确定系统范围，产生系统功能图这一步是确定系统的范围。在和用户经过充分讨论的基础上，明确用户业务活动中，哪些工作由计算机系统来做，哪些由人工来做，对用户的数据需求，以一个个具体的功能确定下来，画出系统功能图。这个功能就是人机界面，一个界面完成一个功能。例如，以我国企业为例，一般的企业进销存管理系统，其功能图如图所示。企业进销存管理系统功能图：一级菜单5.2.1需求分析的工作步骤

3.分析用户业务活动涉及的数据，产生数据流程图深入分析每一个功能需求，以数据流程图的形式表示出数据的流向和对数据所进行的加工。重点是分析各功能之间，数据流向的关联性。数据流程图（DataFlowDiagram，DFD）是从“数据”和“数据的加工”两个方面表达数据处理系统工作过程的一种图形表示，它非常直观，且能被用户和计算机专业人员都能理解。

例如，我国企业进销存、应收应付业务数据流程图，如图所示。企业进销存、应收应付业务数据流程图：5.2.1需求分析的工作步骤

4.分析系统数据，产生数据字典数据字典是用户业务功能中各种数据描述的集合，是对数据流程图的详细描述，它以特定的格式记录系统中各种数据的名称、结构、意义及约束条件等。在需求分析阶段，数据字典是进行数据收集和需求分析后所获得的重要成果，是概念设计最详细的资料来源，也是系统验收的重要依据。5.2.2数据字典的内容及格式数据字典一般包括数据项、数据结构、数据存储、数据流和处理过程等5个部分。数据项是数据的最小单位，若干个数据项可以组成一个数据结构。数据字典是通过数据项和数据结构的定义来描述数据流和数据存储内容的。

1.数据项数据项的描述格式通常如下：

数据项描述={数据项名，语义说明，数据类型，长度，取值范围，其他约束或关联}。5.2.2数据字典的内容及格式

2.数据结构数据结构是反映数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若各个数据结构组成，或者由若干个数据项和数据结构组成。描述数据结构的格式通常为：

数据结构={数据结构名称，含义说明，组成说明}。

2.数据流数据流是数据结构在系统内传输的路径。描述数据流的格式通常为：

数据流={数据流名称，语义说明，数据流来源，数据流去向，组成说明，平均流量，高峰期流量}5.2.2数据字典的内容及格式4.数据存储（文件）数据存储是数据流程图中，数据结构停留或保存的地方，它是业务流程产生的文档或单据。每个用户一般都有自己的文档格式，调研时，要注意向用户收集。

描述数据存储的格式通常为：

数据存储={数据存储名，说明，编号，流入数据流，流出数据流，组成：{数据结构}，数据量，存取方式}5.2.2数据字典的内容及格式5.处理过程数据处理是数据流程图中功能模块的说明。数据字典中一般只需要描述数据处理过程的说明性信息即可。下面以销售管理中，销售订单为例，说明数据字典的具体格式内容。

单据描述：销售订单是公司与客户建立起销售关系的书面文档，订单上记载了客户、货品等详细资料，也为公司发货和收取应收款提供依据。5.2.2数据字典的内容及格式

数据项：销售订单主表

=订单编号+客户编号+订单日期+发货日期+账单地址+发货地址+销售部门+销售员+付款条件+支付方式+发货方式+备注+小计+税率+税额+折扣+运费+合计+制单人+是否审核+审核人+审核日期+订单状态+发货状态+是否有效

销售订单明细表

=订单编号+货品编号+货品单位+货品单价+税额+货品数量+金额编码规定：系统自动编号或手工输入。销售订单主表：数据项名数据类型长度格式是否为空缺省值说明订单编号字符型10否客户编号字符型10否客户字典订单日期日期型8否发货日期日期型8账单地址字符型200发货地址字符型200销售部门字符型10部门字典销售员编号字符型16员工字典付款条件字符型10付款条件字典支付方式字符型10支付方式字典发货方式字符型10发货方式字典备注备注型255小计浮点型15否等于明细表金额之和销售订单主表：数据项名数据类型长度格式是否为空缺省值说明税率浮点型6税额浮点型12折扣浮点型12运费浮点型12合计浮点型15否合计=小计+税额+运费-折扣制单人字符型16否员工字典是否审核逻辑型1否未审核审核人字符型16员工字典审核日期日期型8订单状态逻辑型1否未关闭发货状态逻辑型1否未发货是否有效逻辑型1否有效销售订单明细表：数据项名数据类型长度格式是否为空缺省值说明订单编号字符型10否销售订单主表货品编号字符型15否货品字典货品单位字符型10否货品单位字典货品单价浮点型12否货品数量浮点型12否金额浮点型15否等于货品单价*数量需求分析结束后，把组织机构图、业务流程图、系统功能图、数据流程图、数据字典等信息，按照软件工程的规范，整合在“软件需求说明书”中，双方签字，作为系统最终验收的标准。5.3概要结构设计本章主要内容：（1）数据库设计概述：概念、目标、方法和原则，及设计的一般步骤（2）需求分析：组织机构图、业务流程图、系统功能图、数据流程图（3）概念设计：局部E-R模型、全局E-R模型、评审（4）逻辑设计：将E-R模型转为关系模型的规则、关系模型的优化（5）物理设计：确定数据库的物理结构、评价数据库的物理结构（6）数据库实现、运行和维护5.3概要结构设计在需求调研阶段，数据库设计人员经过充分的调查、分析，然后记录了用户的各种应用需求。这些需求只是现实世界的具体要求，下一步应该把这些需求抽象为信息世界的数据结构，才能够通过计算机实现用户的具体需求。

将需求分析阶段获得的用户详细需求，转换为信息结构（即概念模型）的过程，就是数据库的概要结构设计。它的目的是分析数据之间的内在联系，在此基础上建立一个抽象的数据模型。这种模型与具体的DBMS无关。5.3概要结构设计概念模型最主要的特点是：从用户需求的角度出发，描述数据库全局的、局部的数据逻辑结构，它根据“软件需求说明书”中的信息，在考虑全局数据结构的基础上，按功能抽象出多个局部的逻辑模块。例如，在企业的进销存管理系统中，按相关功能和数据流程，抽象出如下7个模块：销售管理模块、应收款模块、采购管理模块、应付款模块、库存管理模块、查询统计模块、系统维护模块。描述概念模型最常用的工具是E-R模型。

5.3.1概念结构设计的主要步骤需求分析一般采用的策略是自顶向下，而概念设计的策略则自底向上。它主要分三步：按功能模块化，先从单个用户的需求出发，为功能相关联的用户建立一个相应的局部概念模型。在这个过程中，要对需求分析的结果进行细化、补充和修改。（1）进行数据抽象，设计局部概念模型

5.3.1概念结构设计的主要步骤将各功能模块的局部概念模型综合起来，就可以得到反映所有用户需求的全局概念模型。在综合的过程中，要注意各局部概念模型对数据对象定义的不一致问题，包括：同名不同义、异名同义和同一事物在不同的模式中被抽象为不同类型的对象等。

另外，还要注意，在合并过程中，还要检查是否产生数据冗余问题。（2）将局部概念模型综合成全局概念模型

5.3.1概念结构设计的主要步骤评审分用户评审与数据库管理员及开发人员专业评审。前者的重点在于设计的概念模型是否准确反映了用户的实际需求。后者则侧重于考察全局概念模型是否完整、各功能模块的划分是否合理、是否存在数据不一致问题、各种文档是否齐全等。（3）评审

5.3.2

E-R模型的设计步骤当数据库设计人员从用户的需求中抽象出实体类型、属性及实体间联系后，用E-R模型建立局部的概念模型步骤如下：最终获得的全局E-R模型是项目的概念模型，它代表了用户的全部数据要求，是沟通“需求”和“设计”的桥梁。它是下一步数据库逻辑结构设计的直接依据，是建立数据库成功的关键。（1）按功能模块，确定实体集及其属性。

（2）确定实体集之间的联系及联系的类别。

（3）将局部的E-R模型，合并为全局的E-R模型。

5.3.2

E-R模型的设计步骤例如，在销售管理模块中，主要的实体集有：客户、业务员、销售订单，销售管理会关联到商品信息和收款信息，但是商品实体属于库存管理模块，收款属于应收款模块。

客户的属性主要有：客户编号、客户名称、客户地址、客户联系人、客户联系电话等。业务员的属性主要有：员工编号、员工姓名、联系电话、入职时间等。

5.3.2

E-R模型的设计步骤

销售订单主表的属性有：订单编号、客户编号、业务员编号、签订日期、收货地址、订单金额、是否审核、审核人、审核日期、已收金额、是否发货、发货日期等。规定：每张订单只有一个客户编号、一个业务员，可以有多种商品，客户可以分多次付款等。

销售订单明细表的属性有：订单编号、商品编号、数量、单价、金额等，其中金额等于数量*单价，从范式原理看，这个金额属于冗余字段，但这种冗余是可以接受的。这是因为主表的订单金额等于明细表中，各金额之和，主表的这个订单金额也是冗余字段。

5.3.2

E-R模型的设计步骤在进销存管理系统中，金额会涉及到后续的很多处理需要，例如财务上的收款冲账、应收款的查询汇总、业务员的业绩汇总等，如果不增加明细表上的金额、订单主表的订单金额，那些后续业务需求会很不方便。销售订单业务的E-R图，如图所示。销售订单业务的E-R图：

5.3.2

E-R模型的设计步骤数据库设计人员应高度重视这个阶段，并在设计过程中反复和用户进行讨论。在确定没有问题后，才能进入下一阶段的设计工作。

在软件工程中，概念设计的阶段性成果，归结在“概念设计书”这份文档里。5.4逻辑结构设计本章主要内容：（1）数据库设计概述：概念、目标、方法和原则，及设计的一般步骤（2）需求分析：组织机构图、业务流程图、系统功能图、数据流程图（3）概念设计：局部E-R模型、全局E-R模型、评审（4）逻辑设计：将E-R模型转为关系模型的规则、关系模型的优化（5）物理设计：确定数据库的物理结构、评价数据库的物理结构（6）数据库实现、运行和维护5.4逻辑结构设计逻辑结构设计的任务，是把概念结构设计阶段获得的、优化后的整体E-R模型转变为具体的DBMS所支持的数据模型。目前的数据库应用系统基本上都是基于关系数据库的，因此，下面只介绍E-R模型向关系数据库模型转换的原则和方法。

5.4.1将E-R模型转为关系模型概念结构设计得到的E-R图是由实体、属性及实体间的联系组成的，而关系模型的逻辑结构是一组关系模式的集合。因此，将E-R模型转为关系模型实际上就是将实体、属性和实体间的联系转为关系模式。具体转换规则如下：

1.对于E-R图中的每一个实体对于E-R图中的每一个实体类型都对应转换为关系模型中的一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的关键码。

5.4.1将E-R模型转为关系模型

2.对于E-R图中的联系

E-R图中的联系主要分三种：一元联系、二元联系、多元联系，二元联系又包括3种（1：1、1：n、m：n）。不同种类的联系转换为关系模式的规则各不相同，下面分开来说明。（1）二元联系中的一对多联系（1：n）这是两个实体间最常见的一种联系，其转换规则是：将1端的关键码加入到n端对应的关系模式中作为“外键”，同时将联系的属性一并加入到该关系模式中。

5.4.1将E-R模型转为关系模型例如，图5-5销售订单业务中，客户的收款信息，对每个客户可以有多次收款记录，每次收款只能对应一个客户，转为关系模式为：

客户模式（客户编号，客户名称，地址，联系人，联系电话）

收款信息模式（收款单号，收款日期，收款金额，客户编号）收款冲账明细表

5.4.1将E-R模型转为关系模型

（2）二元联系中的多对多联系（m：n）对于两个实体间的m：n联系，其转换规则是：将联系类型转换为一个关系模式，其属性为两边的实体关键码，加上联系类型的属性，而键为两端实体类型关键码的组合。例如，图5-5销售订单业务中，客户的销售订单信息，每张销售订单可以含多种商品，每种商品可以被多个订单销售，转为关系模式为：业务员模式（员工编号，员工姓名，入职日期）

商品模式（商品编号，商品名称，规格，单位，售价，成本价）

销售订单（订单单号，订单日期，收货地址，订单金额，客户编号，员工编号）

销售订单明细模式（订单单号，商品编号，单价，数量，金额）

5.4.1将E-R模型转为关系模型（3）二元联系中的一对一联系（1：1）对于两个实体间的1：1联系，只需在一个关系模式中增加另一个关系模式的键即可。例如，校长与学校的“管理”联系，属于1：1联系。一个学校只能有一个校长，一个校长只能管理一个学校。这时，有两种方法转换为关系模式。可以把校长作为主表，则：

校长模式（校长编号，姓名，性别，年龄，学历，职称）

学校模式（学校编号，学校名称，地址，校长编号）也可以把学校作为主表，则：学校模式（学校编号，学校名称，地址）

校长模式（校长编号，姓名，性别，年龄，学历，职称，学校编号）

5.4.1将E-R模型转为关系模型（4）三元及三元以上的联系这种联系的转换，与其联系的类别有关，基本上可以参照二元联系的转换规则进行。例如，在三元联系中，常见的有如下几种：1：1：n、1：m：n、m：n：p。对于多对多联系的，要将联系类型转换为一个关系模式；对于一对多的联系，只需在多端这边，转为关系模式时，加入一个外键，即可。

5.4.2数据模型的优化将所有的E-R图转换为关系模式后，为了提高数据库应用系统的性能，还应以关系规范化理论为指导，对已经产生的关系模型进行优化。具体的优化步骤为：（1）确定每个关系模式内，属性之间的函数依赖。

（2）确定每个关系模式内，除必要的冗余属性外，是否达到了3NF或BCNF标准。

（3）对照需求分析的结果，检查每个关系模式设计得是否合适。如果不合适，是否需要将某些关系模式进行合并或分解。

（4）检查每个关系模式的关键码或外键，设置得是否合理。在关系模型的规范化实践中，最小冗余度和规范化级别并不是绝对的。关系模式一般能够达到3NF或BCNF级别，已经很完美了。对于数据更新频度不高、但查询频度极高的关系模式，适当保留部分冗余属性，更能提高数据库的应用性能。5.5物理结构设计本章主要内容：（1）数据库设计概述：概念、目标、方法和原则，及设计的一般步骤（2）需求分析：组织机构图、业务流程图、系统功能图、数据流程图（3）概念设计：局部E-R模型、全局E-R模型、评审（4）逻辑设计：将E-R模型转为关系模型的规则、关系模型的优化（5）物理设计：确定数据库的物理结构、评价数据库的物理结构（6）数据库实现、运行和维护5.5物理结构设计数据库的物理结构设计相对来说比较简单，发挥的空间不大。它主要是利用DBMS提供的方法、技术，以较好的数据存储结构和存储方式，将数据库的逻辑结构转换为数据库的物理结构。其目标是：节省存储空间、提高数据查询速度、降低数据库的维护代价。数据库的物理结构设计，通常分为下列两步：（1）确定数据库的物理结构。在关系数据库中，主要指存储结构和存取方法。

（2）对数据库的物理结构进行评价。主要是评价“时间和空间效率”。5.2需求分析开发人员必须高度重视系统的需求分析工作。因为需求分析的内容是否准确反映了用户的实际需求，将直接影响到后面各个阶段的设计工作。一点点偏差，都会导致整个数据库设计返工。5.2.1需求分析的工作步骤开发人员必须高度重视系统的需求分析工作。因为需求分析的内容是否准确反映了用户的实际需求，将直接影响到后面各个阶段的设计工作。一点点偏差，都会导致整个数据库设计返工。

5.5.1确定数据库的物理结构主要是确定数据的存放位置和存储结构，具体内容包括：

1.通过创建数据库，确定数据的存放路劲和存储结构例如，在MySQL中，下列语句创建了一个名为MyTest的数据库： CreateDataBase

MyTest;

创建成功后，MySQL会在数据库默认安装的数据路径下，自动新建一个文件夹“\MyTest”，然后所有该数据库下的资源，都会置于该路径下。

5.5.1确定数据库的物理结构再例如，在MSSQLServer中，创建一个名为student的数据库：12345678910111213141516

CreateDatabasestudenton/*----------------------创建数据库--------------------*/( name=student_data,/*数据文件逻辑名*/

FileName='d:\data\student_data.mdf',/*数据文件物理名*/ Size=10MB,

/*数据库物理文件初始大小*/

Maxsize=200MB,

/*数据库物理文件大小的上限*/

FileGrowth=5

/*剩余空间不足后，物理文件按5%增长*/)Logon( name=student_log,

/*日志文件逻辑名*/

FileName='d:\data\student_log.ldf',/*日志文件物理名*/ Size=5MB,

/*数据库日志文件初始大小*/

Maxsize=25MB,

FileGrowth=5MB);

5.5.1确定数据库的物理结构创建成功后，会在指定的路径下，生成2个物理文件，一个是数据文件，后缀名为*.mdf，一个是日志文件，后缀为*.ldf，所有数据库资源都置于这2个文件中。同时还指定了2个文件的初始大小、上限，以及文件的增长幅度。

5.5.1确定数据库的物理结构

2.创建基本表，包括表的属性、主键、或外键，表的各种约束这是最重要的部分，具体参见例题3.2。

3.创建索引对于查询比较频繁的属性列，可以创建簇索引，或非簇索引。对于取值唯一性的非主属性列，可以创建唯一性（Unique）索引。

4.创建视图为了隐蔽数据的复杂性，简化用户对数据的操作，或对某些机密数据进行保护，可以创建视图，具体参见3.5节。

5.5.1确定数据库的物理结构

5.创建触发器为了满足用户对某些数据处理的特殊要求，可以创建触发器，具体参见8.3节。

6.完整性和安全性考虑设计人员应在完整性、安全性、有效性和效率方面进行分析，并作出权衡。

5.5.2评价数据库的物理结构在数据库物理设计过程中，根据表的数据流量和属性列的访问频率，需要对时间效率、空间效率、维护代价和用户的各种要求进行权衡，其结果可能产生多种