数据库设计规范化的五个要求(转载)

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

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

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

　　因此，虽然在数据库表设计的时候，容许表中具备空字段，可是，咱们应该尽可能避免。若确实须要的话，咱们能够经过一些折中的方式，来处理这些空字段，让其对数据库性能的影响下降到最少。

　　一是经过设置默认值的形式，来避免空字段的产生。如在一我的事管理系统中，有时候身份证号码字段可能容许为空。由于不是每一个人均可以记住本身的身份证号码。而在员工报到的时候，可能身份证没有带在身边。因此，身份证号码字段每每不能及时提供。为此，身份证号码字段能够容许为空，以知足这些特殊状况的须要。可是，在数据库设计的时候，则能够作一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以免空字段的产生。

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

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

　　如如今有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候能够是一我的完成，而有时候又须要多我的合做才可以完成。因此，在产品基本信息表产品开发者这个字段中，有时候可能须要填入多个开发者的名字。

　　如进销存管理中，还须要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。可是在必要的状况下，企业须要对客户的采购表明、仓库人员、财务人员共同进行管理。由于在订单上，可能须要填入采购表明的名字;但是在出货单上，则须要填入仓库管理人员的名字等等。

　　为了解决这个问题，有多种实现方式。可是，若设计不合理的话在，则会致使重复的值或者列。如咱们也能够这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，能够设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则每每还须要加入更多的字段。

　　但是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就创建六个联系人字段?这不但会致使空字段的增长，还须要频繁的更改数据库表结构。明显，这么作是不合理的。也有人说，能够直接修改采购员的名字呀。但是这么处理的话，会把原先采购订单上采购员的名字也改变了。由于采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变了的状况下，采购订单上显示的就是更改后的名字。这不利于时候的追踪。

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

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

　　在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来惟一的标识行记录，而不要经过名字、编号等字段来对纪录进行区分。每一个表都应该有一个ID列，任何两个记录都不能够共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。不然的话，很容易产生ID值不统一的状况。

　　另外，在数据库设计的时候，最好还可以加入行号。如在销售订单管理中，ID号是用户不可以维护的。可是，行号用户就能够维护。如在销售订单的行中，用户能够经过调整行号的大小来对订单行进行排序。一般状况下，ID列是以1为单位递进的。可是，行号就要以10为单位累进。如此，正常状况下，行号就以十、20、30依次扩展下去。若此时用户须要把行号为30的纪录调到第一行显示。此时，用户在不可以更改ID列的状况下，能够更改行号来实现。如能够把行号改成1，在排序时就能够按行号来进行排序。如此的话，原来行号为30的纪录如今行号变为了1，就能够在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没有的。须要在实际应用程序设计中，才会掌握到这个技巧。

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

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

　　为此，笔者创建，在开发数据库以前，最好可以花必定的时间，去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用程序协商，肯定合理的命名规范。笔者最经常使用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表能够用M为前缀;而以订单管理相关的，则能够利用C做为前缀。具体采用什么前缀能够以用户的爱好而定义。可是，须要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，而且严格按照这个命名规范来定义对象名。

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

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

　　这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所须要描述对象的自己。笔者举一个例子，估计你们就能够明白其中的内容了。如如今有一个图书馆里系统，有图书基本信息、做者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是能够的。如能够把表设计成图书名字、图书做者等等。但是如此设计的话，会给后续的维护带来很多的麻烦。

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

　　遇到这种状况时，笔者建议能够把上面这张表分解成三种独立的表，分别为图书基本信息表、做者基本信息表、图书与做者对应表等等。如此设计之后，以上遇到的全部问题就都引刃而解了。

　　以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有不少细节方面的要求，如数据类型、存储过程等等。并且，数据库规范每每没有技术方面的严格限制，主要依靠数据库管理员平常工做经验的累积。

 

原文地址http://space.itpub.net/7698721