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

数据库设计规范化五个要求
数据库设计规范化五个要求
1 / 141
数据库设计规范化五个要求
通常情况下，可以从两个方面来判断数据库是否设计的比拟标准。
一是看看是否拥有大量的
窄表，二是宽表的数量是否足够的少。
置一张表。
然后通过客
ID把供给商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
要求三：表中记录应该有一个唯一的标识符
在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个 ID号来唯一的标
识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个 ID列，
任何两个记录都不可以共享同一个 ID值。另外，这个 ID值最好有数据库来进行自动管理，
而不要把这个任务给前台应用程序。否那么的话，很容易产生 ID值不统一的情况。
另外，在数据库设计的时候，最好还能够参加行号。如在销售订单管理中， ID号是用
户不能够维护的。但是， 行号用户就可以维护。如在销售订单的行中， 用户可以通过调整行
号的大小来对订单行进行排序。通常情况下， ID列是以 1为单位递进的。但是，行号就要
以10为单位累进。如此，正常情况下，行号就以 10、20、30依次扩展下去。假设此时用户需
要把行号为 30的纪录调到第一行显示。 此时，用户在不能够更改 ID列的情况下，可以更改
行号来实现。如可以把行号改为 1，在排序时就可以按行号来进行排序。如此的话，原来来
行号为30的纪录现在行号变为了 1，就可以在第一行中显示。这是在实际应用程序设计中
对ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才
会掌握到这个技巧。
要求四：数据库对象要有统一的前缀名
一个比拟复杂的应用系统， 其对应的数据库表往往以千计。 假设让数据库管理员看到对象
名就了解这个数据库对象所起的作用， 恐怕会比拟困难。 而且在数据库对象引用的时候， 数
据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
为此，笔者建立，在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象
的前缀命名标准。如笔者在数据库设计时， 喜欢跟前台应用程序协商， 确定合理的命名标准。
笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。 如跟物料管理模块
相关的表可以用 M为前缀;而以订单管理相关的，那么可以利用 C作为前缀。具体采用什么前
缀可以以用户的爱好而定义。 但是，需要注意的是，这个命名标准应该在数据库管理员与前
台应用程序开发者之间达成共识，并且严格按照这个命名标准来定义对象名。
其次，表、视图、函数等最好也有统一的前缀。如视图可以用 V为前缀，而函数那么可以
利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候， 都能够在最短的
时间内找到自己所需要的对象。
要求五：尽量只存储单一实体类型的数据
这里将的实体类型跟数据类型不是一回事， 要注意区分。这里讲的实体类型是指所需要
描述对象的本身。 笔者举一个例子， 估计大家就可以明白其中的内容了。 如现在有一个图书
馆里系统，有图书根本信息、 作者信息两个实体对象。 假设用户要把这两个实体对象信息放在
同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，
会给后续的维护带来不少的麻烦。
如当后续有图书出版时， 那么需要为每次出版的图书增加作者信息， 这无疑会增加额外的
存储空间，也会增加记录的长度。而且假设作者的情况有所改变，如住址改变了以后，那么还需
要去更改每本书的记录。 同时，假设这个作者的图书从数据库中全部删除之后， 这个作者的信
息也就荡然无存了。很明显，这不符合数据库设计标准化的需求。
遇到这种情况时， 笔者建议可以把上面这张表分解成三种独立的表， 分别为图书根本信
息表、作者根本信息表、 图书与作者对应表等等。 如此设计以后，以上遇到的所有问题就都
引刃而解了。
以上五条是在数据库设计时到达标准化水平的根本要求。 除了这些另外还有很多细节方
面的要求，如数据类型、存储过程等等。而且，数据库标准往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
数据库设计规范化五个要求
数据库设计规范化五个要求
4 / 144
数据库设计规范化五个要求
数据表的设计原那么 :
不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个
组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之间的