《数据库设计规范化的五个要求》由会员分享，可在线阅读，更多相关《数据库设计规范化的五个要求（12页珍藏版）》请在金锄头文库上搜索。
1、通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表， 二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。要求一：表中应该避免可为空的列虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，
2、我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0 或者为N/A。以避免空字段的产生。二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且， 这些列在大部分情况下，都是
3、可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表， 以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。要求二：表不应该有重复的值或者列如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以， 在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。如进销存管理中，还需要对客户的联系人进行管理。有时候， 企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员
4、、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字; 可是在出货单上，则需要填入仓库管理人员的名字等等。为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时， 在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的
5、更改数据库表结构。明显，这么做是不合理的。也有人说，可以直接修改采购员的名字呀。可是这么处理的话，会把原先采购订单上采购员的名字也改变了。因为采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变了的情况下，采购订单上显示的就是更改后的名字。这不利于时候的追踪。所以， 在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户 ID 把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段
6、把这些独立的表联系起来。要求三：表中记录应该有一个唯一的标识符在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID 号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID 列，任何两个记录都不可以共享同一个ID 值。另外，这个ID 值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID 值不统一的情况。另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID 号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID 列是以 1 为
7、单位递进的。但是，行号就要以 10 为单位累进。如此，正常情况下，行号就以10、 20、 30 依次扩展下去。若此时用户需要把行号为30 的纪录调到第一行显示。此时， 用户在不能够更改ID 列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来来行号为 30 的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对 ID 列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。要求四：数据库对象要有统一的前缀名一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数
8、据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。为此， 笔者建立，在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用程序协商，确定合理的命名规范。笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用 M为前缀；而以订单管理相关白1则可以利用 C作为前缀。具体采用什么前缀可以以用户的爱好而定义。但是， 需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。其次，
9、表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用 F 为前缀。 如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。要求五：尽量只存储单一实体类型的数据这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。如当后续有图书出版时，则需要为每次
10、出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时， 若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、 作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据
11、库管理员日常工作经验的累积。+数据表的设计原则(1)不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个 组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。(2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务， 根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之 内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有
12、一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。(3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个 表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。(4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对 象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表
13、应满足第二范式，且属性间不存在传递依赖。(5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系， 所以在领域模型中的对象存在主对象和从对象之分，从对象是从1-N或N-N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。(6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在 多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则 证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式： 一个表如果满足BCNF不应存在多值依赖。(7)在经过分析后确认所有的表都
14、满足二、三、四范式的情况下，表和表之间的关联尽 量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务(数据间的一致性)，这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据(脏数据)的兼容性。当然，从整个系统的角度来说我们还 是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。(8)应针对所有表的主键和外键建立索引，有针对性的(针对一些大数据量和常
15、用检索方式)建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在 检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。(9)尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象 /关系 映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过 程。(10)当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。(11)设计出的表要具有较好的使用性，主要体
