数据库设计

『壹』 数据库设计怎么做

两个不同实体间的1:n关系

上图中表示的是一辆汽车与零件之间的1:n关系，一辆汽车由许多个零件构成。“汽车”这个实体具有型号、单价和牌号等属性，“零件”这个实体具有名称、单价和厂家等属性，“数量”是它们之间的关系“组成”的一个属性。

当然E-R图还可以表示1:1关系，例如夫妻关系以及姓名与学号间的关系等。

E-R图还可以表示m:n关系，例如教材中中讲的“学生”与“课程”之间通过“学习”联系，一个学生要学习多门课程，反之同一门课程有很多学生在学习。

在E-R图中，有时为了使其简洁明了，图中可以略去各属性，着重表示实体间的联系情况，而属性可以单独以表格形式单独列出。

4.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图所表示的实体联系模型，只能说明实体间的联系关系，还需要把它转换成数据模型才能被实际的DBMS所接受。

2.3.3 从E-R图导出关系模型

E-R图是现实世界各实体的具体反映，与数据库具体实现毫无关系，但它却是构造数据模型的主要依据。本章的重点也是难点是：正确地应用E-R图反映实体间联系并从E-R图中导出关系模型。

1.从E-R图中导出关系模型的原则

（1）对于E-R图中的每一个实体，都应转换为一个关系，该关系应包括对应实体的全部属性，并应根据关系所表达的语义确定哪个属性（或哪几个属性组合）作为“主键”。键在关系模型中是实现联系的主要手段。

（2）对于E-R图中的联系，情况比较复杂，要根据实体联系的方式的不同，采取不同的手段加以实现。

2.从E-R图中导出关系模型

（1）两实体间1:n联系

对于两实体间1:n联系，导出关系模型的原则是：可以将“1”方实体的“主键”纳入“n”方实体对应的关系中作为“外部键”，同时把联系的属性也一并纳入“n”方对应的关系中。

（2）同一实体内部个体间1:n联系

对于同一实体集内部个体间的1:n联系，导出关系模型的原则是：可在这个实体所对应的关系中多设一个属性，用来作为与该实体相联系的另一个体的“主键”。

（3）两实体间m:n联系

对于两实体间的m:n联系，导出关系模型的原则是：必须对“联系”单独建立一个关系，用来联系双方实体；该关系的属性中至少要包括被它所联系的双方实体的“主键”，并且如果联系有属性，也要归入这个关系中。

（4）同一实体内部存在m:n的联系

如果同一实体内部存在m:n的联系，那么从E-R图导出关系模型的原则是“为这个联系单独建立一个关系；该关系中至少应包括被它所联系的双方实体的“主键”，如果联系有属性，也要归入这个关系中。

（5）两个以上实体间m:n多元联系

对于两个以上实体之间的m:n多元联系，从E-R图导出关系模型的原则是：必须为联系单独建立一个关系，该关系中最少应包括被它联系的各个实体的“主键”，若是联系有属性，也要归入这个关系中。

（6）两实体间1:1联系

对于两实体间1:1联系，只需在一个关系模型中增加另一个关系模型的主键，并可省略两实体间的联系模型。例如：书中所讲到的厂家与工厂的关系，可以省去“管理”这个模型，在“工厂”模型中加入属性“姓名”或在“厂长”模型中加入“工厂”的主键“厂号”，这样关系模型就形成了。

『贰』 数据库设计原则

本系统中数据库的设计，要考虑和遵循下列数据库设计的基本原则，以建立稳定、安全内、可靠的容数据库。

1)一致性原则:对数据来源进行统一、系统的分析与设计，协调好各种数据源，保证数据的一致性和有效性。

2)完整性原则:数据库的完整性是指数据的正确性和相容性。要防止合法用户使用数据库时向数据库加入不合语义的数据。对输入到数据库中的数据要有审核和约束机制。

3)安全性原则:数据库的安全性是指保护数据，防止非法用户使用数据库或合法用户非法使用数据库造成数据泄露、更改或破坏。要有认证和授权机制。

4)可伸缩性与可扩展性原则:数据库结构的设计应充分考虑发展的需要、移植的需要，具有良好的扩展性、伸缩性和适度冗余。

5)规范化:数据库的设计应遵循规范化理论。规范化的数据库设计，可以减少数据库插入、删除、修改等操作时的异常和错误，降低数据冗余度等。

『叁』 数据库设计分哪几个阶段

按照规范的设计方法，一个完整的数据库设计一般分为以下六个阶段。

1、需求分专析属：分析用户的需求，包括数据、功能和性能需求

2、概念结构设计：主要采用E-R模型进行设计，包括画E-R图

3、逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换

4、数据库物理设计：主要是为所设计的数据库选择合适的存储结构和存取路径

5、数据库的实施：包括编程、测试和试运行

6、数据库运行与维护：系统的运行与数据库的日常维护

(3)数据库设计扩展阅读：

设计原则

1、一对一设计原则

在软件开发过程中，需要遵循一对一关系设计原则进而开展数据维护工作，通过利用此原则能够尽量减少维护问题的出现，保证数据维护工作顺利开展同时降低维护工作难度。

2、独特命名原则

独特命名原则的应用是为了减少在数据库设计过程中出现重复命名和规范命名现象出现。

3、双向使用原则

双向使用原则包括：事务使用原则和索引功能原则，软件市场常见的索引模式有：多行检索聚簇索引和单行检索非聚簇索引。

『肆』 数据库设计的基本步骤

数据库设计的基本步骤如下：

1、安装并打开MySQL WorkBench软件以后，在软件的左侧边栏有三个选项，分别是对应“连接数据库”、“设计数据库”、“迁移数据库”的功能。这类选择第二项，设计数据库，点击右边的“＋”号，创建models。

『伍』 数据库设计主要包括哪几部分，分别包括哪些内容

数据库设计主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护，具体内容如下：

1、需求分析

内容：调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2、概念设计

内容：对用户要求描述的现实世界，通过对其中诸处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。

3、逻辑设计

内容：主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

4、物理设计

内容：根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。

5、验证设计

内容：收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般，一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时，可能就需要返回到前面去进行修改。

6、运行与维护设计

内容：在数据库系统正式投入运行的过程中，必须不断地对其进行调整与修改。除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外，尚缺乏一套完善的数据库设计理论、方法和工具，以实现数据库设计的自动化或交互式的半自动化设计。

(5)数据库设计扩展阅读：

重要性

1、有利于资源节约

对计算机软件数据库设计加以重视不仅可减少软件后期的维修，达到节约人力与物力的目的，同时还有利于软件功能的高效发挥。

2、有利于软件运行速度的提高

高水平的数据库设计可满足不同计算机软件系统对于运行速度的需求，而且还可充分发挥并实现系统功能。计算机软件性能提高后，系统发出的运行指令在为用户提供信息时也将更加快速有效，软件运行速度自然得以提高。

3、有利于软件故障的减少

加强数据库设计可有效减少软件故障的发生几率，推动计算机软件功能的实现。

『陆』 .数据库设计分为几个阶段,各阶段的任务是什么

按照规范的设计方法，一个完整的数据库设计一般分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库的实施、数据库运行与维护六个阶段：

各阶段的任务如下：

1、需求分析：分析用户的需求，包括数据、功能和性能需求；

拓展资料：

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂，因此最佳设计不可能一蹴而就，而只能是一种"反复探寻，逐步求精"的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

『柒』 中心数据库设计

5.2.2.1 数据库

根据该系统的开发需求，按照数据库的功能和作用将其分为风险查询类、风险评价类、系统管理类三大类（萨师煊等，2000）。主要数据见表5.5。

表5.5 海外油气与金属矿产资源开发风险管理系统的主要数据表

续表

5.2.2.2 数据仓库

油价数据来源于美国能源部（DOE）下属的能源信息署（EIA）网站、中石油（CNPC）网站和《华尔街日报》（WSJ）网站提供的油价数据，油价序列本身就是一个不规则的时间序列，油价数据具有以下几个特点。

（1）数据的一致性差

油价数据格式多样，存在数据冗余，主要体现在：使用的数据格式均不相同，并且各个子系统相对独立。在网站单独作用的情况下，一般都没有问题，但要将这些不同系统或不同时期的数据集中起来综合利用，就可能出现数据不齐全、不一致或重复的现象。

（2）数据存放的分散

油价数据来源多，缺乏统一管理，没有一种相应的网页数据自动化抓取操作实现数据的本地化操作过程。

（3）数据资源开发不充分

大容量数据导致对数据资源的开发利用不充分，缺乏对获取的数据如各分析机构制定的期货合约元数据进行各种深层次分析、综合、提炼、挖掘和展现的应用，因此很难对丰富的统计数据资源进行二次开发利用。

根据油价数据中所包含的油气产品种类、油气产品合约制定日期、油气产品的价格类型、不同市场下油气产品价格的差异等，能够加深对油价走势的了解。油价的这种与时间相关性、不可修改性，以及集成的性质，使得我们采用多种角度对原始数据进行理解，并真实反映其特性，也让我们发现使用一种整合的技术对油价进行精确预测十分必要。

数据仓库的构建流程如图5.13所示由下至上逐步实现。

图5.13 数据仓库构建流程

1）数据源。

A.数据源的复杂性。数据分散在数据库管理系统、电子表格、电子邮件系统、电子文档甚至纸上。系统中要求采集的3个数据源中，EIA 网站存储在网页上的油价相关事件更新较慢，虽然提供了各市场日、周、月、年的油价数据下载，但是下载完成之后的表格字段格式时常发生变化，这为实现自动获取数据并下载到本地自动入库的要求增加了难度；中石油网站数据除上述只显示3条数据之外，网站上会将访问流量过大的IP地址列入黑名单使其不能继续下载到本地进行保存，为这些数据建立统一的模型将会耗费很大精力。

B.数据的有效性。由于存在经验局限，如何处理数据的空值、不同时间间隔时间字段格式，入库时应注意的问题等，如果应用程序没有检验数据的有效性，会对数据多维显示产生极大影响，因此也归结为数据源数据质量问题。

C.数据的完整性。数据源上的数据并不那么明显或者容易获得。油价是高度敏感的数据，因此各个网站虽然提供了各个油品交易市场的日、月或年数据，但是完整性并不能充分保证，根据企业政策的不同，有时对要获得的数据，需花费大量精力。为此，要对不同的数据源进行建库，以保证所获数据的完整性。

2）数据处理。

高效的多维数据集展示离不开底层数据源数据的精确获取，或者叫做数据理解和数据清洗。于是系统在基于元数据获取、加工、入库和多维数据集展示上实现预期的要求。

A.ETL。该功能是整个油价数据仓库的核心之一，主要功能是按照事先定义的数据表对应关系从相关系统表中抽取数据（Extraction），经过数据清洗和转换（Transform）,最终把正确的数据装载到数据仓库的源数据中（Load），作为以后应用的基础。

B.数据转换。该功能是在数据抽取过程中按照定义的规则转换数据，避免了数据在分析时的多样性，保证数据一致性。

C.数据集成。该功能主要是把油价信息数据仓库系统的源数据，按照事先定义的计算逻辑以主题的方式重新整合数据，并以新的数据结构形式存储。

3）数据存储。

星型模型（星型架构）是数据仓库开发中多维展现重要的逻辑结构，构成星型模型的几个重要特征是：维、度和属性，在实际应用中表示为事实表和维度表。在油价数据中，各市场的期现货价格表为数据仓库的事实表，油品类型、合约规定日期等为维度表。

油价数据仓库星型模型的设计方案如下：

A.事实表。数据库表中EIA的期现货价格表（包括日、周、月、年表）作为数据仓库中的事实表，根据不同时间维度构成多个星型模型，即星座模型。这些价格表中以市场编号、油气产品类型、期货合约日期、价格单位度量衡编号作为主键和外键与其他维度表相连，形成多维展示联动的基础，以油价数据和其他事实数据为记录数据，作为主要输出结果。

B.维度表。根据市场、油品、价格数据、度量衡和事件类型作为油气数据仓库中多维分析的角度和目标。

图5.14以EIA的日期货数据表作事实表为例，构建星型模型，其他不同时间维度的模型结构图与此图基本相同。

图5.14 以EIA数据为例的日期货价格星型模型

以星型模型设计为基础，完善数据存储中操作型数据存储（ODS）的原型设计，提供DB-DW之间中间层的数据环境，可实现操作型数据整合和各个系统之间的数据交换。

『捌』 如何进行数据库的设计

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统
(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的
功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
(3)数据库设计是信息系统开发和建设的重要组成部分。
(4)数据库设计人员应该具备的技术和知识：
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识

二、数据库设计的特点
数据库建设是硬件、软件和干件的结合
三分技术，七分管理，十二分基础数据
技术与管理的界面称之为“干件”
数据库设计应该与应用系统设计相结合
结构（数据）设计：设计数据库框架或数据库结构
行为（处理）设计：设计应用程序、事务处理等
结构和行为分离的设计
传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计
如图：

三、数据库设计方法简述
手工试凑法
设计质量与设计人员的经验和水平有直接关系
缺乏科学理论和工程方法的支持，工程的质量难以保证
数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法
手工设计方
基本思想
过程迭代和逐步求精
规范设计法(续)
典型方法：
(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段
S.B.Yao方法：将数据库设计分为五个步骤
I.R.Palmer方法：把数据库设计当成一步接一步的过程
(2)计算机辅助设计
ORACLE Designer 2000
SYBASE PowerDesigner

四、数据库设计的基本步骤
数据库设计的过程(六个阶段)
1.需求分析阶段
准确了解与分析用户需求（包括数据与处理）
是整个设计过程的基础，是最困难、最耗费时间的一步
2.概念结构设计阶段
是整个数据库设计的关键
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
3.逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型
对其进行优化
4.数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
5.数据库实施阶段
运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果
建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
6.数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改
设计特点:
在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

设计过程各个阶段的设计描述：
如图：

五、数据库各级模式的形成过程
1.需求分析阶段：综合各个用户的应用需求
2.概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)
3.逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
4.物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

六、数据库设计技巧

1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。

2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则
4) 每个表中都应该添加的3 个有用的字段
dRecordCreationDate，在VB 下默认是Now()，而在SQL Server • 下默认为GETDATE()
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT • USER
nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因 •
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
为关联字段创建外键。 •
所有的键都必须唯一。 •
避免使用复合键。 •
外键总是关联唯一的键字段。 •
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。

索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

4. 数据完整性设计（数据库逻辑设计）
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。