2023年7月27日发(作者：)

数据库设计规范化的五个要求

数据库逻辑设计是优化关系数据库的核心。而数据库设计的规范化则是这个核心的核心。一个规范化的逻辑数据库，可以为数据库管理员优化数据库和应用程序性能打下坚实的基础。相反，若逻辑数据库设计不规范，则会损害整个数据库，包括应用程序的性能。

通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。

要求一：表中应该避免可为空的列

虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。

所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

一是通过设置默认值的形式，来避免空字段的产生。

二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。

要求二：表不应该有重复的值或者列

如进销存管理中，还需要对客户的联系人进行管理。而一个客户的联系人可能有多个，为了解决这个问题，有多种实现方式。若设计不合理的话在，则会导致重复的值或者列。我们可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。

可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。直接修改又不利于追踪。

所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。

要求三：表中记录应该有一个唯一的标识符。

在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。 另外，在数据库设计的时候，最好还能够加入行号。ID号是用户不能够维护的。但是，行号用户就可以维护。这是在实际应用程序设计中对ID列的一个有效补充。

要求四：数据库对象要有统一的前缀名。

一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。

建议：在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范。最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。

其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。

要求五：尽量只存储单一实体类型的数据。

实体类型跟数据类型不是一回事，要注意区分。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。

如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。

遇到这种情况时，建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。 数据库设计规范

一、数据库设计过程

数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。

数据库设计的各阶段：

A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。

B、概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。

C、逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。

D、物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

1. 需求分析阶段

需求收集和分析，得到数据字典描述的数据需求和数据流图描述的处理需求。

需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。

常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。

分析和表达用户需求的方法：主要包括自顶向下和自底向上两类方法。采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。

据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。

2. 概念结构设计阶段

概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。

概念模型特点：

(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。

(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。

创建E-R模型的步骤如下所示:

2.1 第零步——初始化工程

这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。

2.2 第一步——定义实体

实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。

2.3 第二步——定义联系

一般模型中只保留二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明。

2.4 第三步——定义码

标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。

2.5 第四步——定义属性

从源数据表中抽取说明性的名词构建属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。

2.6 第五步——定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。

3. 逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。一个多对多的联系转换为一个关系模式，两个实体的码和联系本身的属性就是关系的属性，两个实体的码就是关系的码。

数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准。

4. 数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

5. 数据库实施阶段

运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行。

6. 数据库运行和维护阶段

在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

7. 建模工具的使用

为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

二、数据库设计技巧

1. 设计数据库之前

1) 理解客户需求，包括用户未来需求变化。

2) 了解企业业务类型，可以在开发阶段节约大量的时间。

3) 重视输入(要记录的数据)、输出(报表、查询、视图)。

4) 创建数据字典和ER 图表

数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。

数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系

数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]

数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量

数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式

处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

2. 表和字段的设计(数据库逻辑设计)

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal

Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。

2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

4) 表名、报表名和查询名的命名规范

(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了

Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象，用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。

字段设计原则：

 每个表中都应该添加的3 个有用的字段。

dRecordCreationDate，在SQL Server 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER

nRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因。

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名

对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用_N 后缀;字符类型：_C

后缀;日期类型：_D 后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。

5) 选择数字类型和文本类型的长度应尽量充足

假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

6) 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

7) 提防大小写混用的对象名和特殊字符

采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。

8) 小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用 DESC

作为说明字段名，后果可想而知! 表里的一个 SELECT * 语句能用，但得到的却是一大堆毫无用处的信息。

9) 保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，在表2里就不要把名字改成 “ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有外键ID，则为了可读性，在表2做关联时可以命名为 ABC_ID。

10) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

3. 选择键和索引(数据库逻辑设计)

参考：《SQL优化-索引》一文 4. 数据完整性设计(数据库逻辑设计)

1) 完整性实现机制：

实体完整性：主键

参照完整性：

父表中删除数据：级联删除;受限删除;置空值

父表中插入数据：受限插入;递归插入

父表中更新数据：级联更新;受限更新;置空值

DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：

NOT NULL;CHECK;触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

6) 关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

7) 给数据保存和恢复制定计划

考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用发布给用户/开发人员的数据字典实现方便的数据识别，同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

8) 用存储过程让系统做重活

提供一整套常规的存储过程来访问，以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。

5. 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

2) 使用常用英语(或者其他任何语言)而不要使用编码 在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

3) 保存常用信息

让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

6) 测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

7) 检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

三、数据库命名规范

1. 实体(表)的命名

1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4 个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推)

对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称统一成大写或者小写中的一种，故中间加上下划线。

2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。

3) 所有的存储值列表的表前面加上前缀Z，目的是将这些值列表类排序在数据库最后。

4) 所有的冗余类的命名(主要是累计表)前面加上前缀X

冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表

5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。关联表用于保存多对多关系。如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。 2. 属性(列)的命名

1) 采用有意义的列名

表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;

A、如果是数据库自动生成的编码，统一命名为：ID

B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”

C、如果键是数字类型，你可以用_NO 作为后缀;

D、如果是字符类型则可以采用_CODE 后缀

E、对列名应该采用标准的前缀和后缀。

2) 所有的属性加上有关类型的后缀

注意，如果还需要其它的后缀，都放在类型后缀之前。

注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。

3) 采用前缀命名

给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。

3. 视图的命名

1) 视图以V作为前缀，其他命名规则和表的命名类似;

2) 命名应尽量体现各视图的功能。

4. 触发器的命名(尽量不使用)

触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。

5. 存储过程名

存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。

6. 变量名

变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。

7. 命名中其他注意事项

1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。

2) 数据对象、变量的命名都采用英文字符（一般禁止使用中文命名）。绝对不要在对象名的字符之间留空格。

3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突

4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。