★数据库设计规范化的五个要求—无忧智考网

凡是情形下，可以年夜两个方面来判定数据库是否设计的斗劲规范。一是看看是否拥有年夜量的窄表，二是宽表的数目是否足够的少。若合适这两个前提，则可以声名这个数据库的规范化水平仍是斗劲高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要合适以下五个要求。
　　要求一：表中应该避免可为空的列。
　　虽然表中许可空列，可是，空字段是一种斗劲非凡的数据类型。数据库在措置的时辰，需要进行非凡的措置。如斯的话，就会增添数据库措置记实的复杂性。当表中有斗劲多的空字段时，在齐截前提下，数据库措置的机能会降低良多。
　　所以，虽然在数据库表设计的时辰，许可表中具有空字段，可是，我们应该尽量避免。若确实需要的话，我们可以经由过程一些折中的体例，来措置这些空字段，让其对数据库机能的影响降低到起码。
　　一是经由过程设置默认值的形式，来避免空字段的发生。如在一小我事打点系统中，有时辰身份证号码字段可能许可为空。因为不是每小我都可以记住自己的身份证号码。而在员工报到的时辰，可能身份证没有带在身边。所以，身份证号码字段往往不能实时供给。为此，身份证号码字段可以许可为空，以知足这些奸细作况的需要。可是，在数据库设计的时辰，则可以做一些措置。如当用户没有输入内容的时辰，则把这个字段的默认值设置为0或者为N/A。以避免空字段的发生。
　　二是若一张表中，许可为空的列斗劲多，接近表全数列数的三分之一。而且，这些列在年夜部门情形下，都是无关紧要的。若数据库打点员碰着这种情形，笔者建议此外成立一张副表，以保留这些列。然后经由过程关头字把主表跟这张副表联系关系起来。将数据存储在两个自力的表中使得主表的设计更为简单，同时也能够知足存储空值信息的需要。
　　要求二：表不应该有一再的值或者列。
　　如斯刻有一个进销存打点系统，这个系统中有一张产物根基信息表中。这个产物开发有时辰可所以一小我完成，而有时辰又需要多小我合作才能够完成。所以，在产物根基信息表产物开发者这个字段中，有时辰可能需要填入多个开发者的名字。
　　如进销存打点中，还需要对客户的联系人进行打点。有时辰，企业可能只知道客户一个采购员的姓名。可是在需要的情形下，企业需要对客户的采购代表、仓库人员、财政人员配合进行打点。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库打点人员的名字等等。
　　为体味决这个问题，有多种实现体例。可是，若设计不合理的话在，则会导致一再的值或者列。如我们也可以这么设计，把客户信息、联系人都放入统一张表中。为体味决多个联系人的问题，可以设置第一愫系人、第一愫系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需冲要手更多的字段。
　　可是这么设计的话，会发生一系列的问题。如客户的采购员流动性斗劲年夜，在一年内换了六个采购员。此时，在系统中该若何打点呢?莫非就成立六个联系人字段?这不单会导致空字段的增添，还需要频仍的更改数据库表结构。较着，这么做是不合理的。也有人说，可以直接改削采购员的名字呀。可是这么措置的话，会把原先采购订单上采购员的名字也改变了。因为采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变了的情形下，采购订单上显示的就是更改后的名字。这晦气于时辰的追踪。
　　所以，在数据库设计的时辰要尽量避免这种一再的值或者列的发生。笔者建议，若数据库打点员碰着这种情形，可以改变一下策略。如把客户联系人此外设置一张表。然后经由过程客户ID把供给商信息表跟客户联系人信息表毗连起来。也就是说，尽量将一再的值放置到一张自力的表中进行打点。然后经由过程视图或者其他手段把这些自力的表联系起来。
　　要求三：表中记实应该有一个独一的标识符。
　　在数据库表设计的时辰，数据库打点员应钙揭捉成一个好习惯，用一个ID号来独一的标识行记实，而不要经由过程名字、编号等字段来对记载进行区分。每个表都应该有一个ID列，任何两个记实都不成以共享统一个ID值。此外，这个ID值最好稀有据库来进行自动打点，而不要把这个使命给前台应用轨范。否则的话，很轻易发生ID值不统一的情形。
　　此外，在数据库设计的时辰，最好还能够插手行号。如在发卖订单打点中，ID号是用户不能够维护的。可是，行号用户就可以维护。如在发卖订单的行中，用户可以经由过程调整行号的巨细来对订单行进行排序。凡是情形下，ID列是以1为单元递进的。可是，行号就要以10为单元累进。如斯，正常情形下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的记载调到第一行显示。此时，用户在不能够更改ID列的情形下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如斯的话，原本行号为30的记载此刻行号变为了1，就可以在第一行中显示。这是在现实应用轨范设计中对ID列的一个有用填补。这个内容在教科书上是没有的。需要在现实应用轨范设计中，才会把握到这个技巧。
　　要求四：数据库对象要有统一的前缀名。
　　一个斗劲复杂的应用系统，其对应的数据库表往往以千计。若让数据库打点员看到对象名就体味这个数据库对象所起的浸染，生怕会斗劲坚苦。而且在数据库对象引用的时辰，数据库打点员也会为不能迅速找到所需要的数据库对象而头疼。
　　为此，笔者成立，在开发数据库之前，最好能够花必然的时刻，去拟定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用轨范协商，确定合理的命名规范。笔者最常用的是按照前台应用轨范的模块来界说后台数据库对象前缀名。如跟物料打点模块相关的表可以用M为前缀;而以订单打点相关的，则可以操作C作为前缀。具体采用什么前缀可以以用户的快乐喜爱而界说。可是，需要注重的是，这个命名规范应该在数据库打点员与前台应用轨范开发者之间告竣共识，而且严酷按照这个命名规范来界说对象名。
　　其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以操作F为前缀。如斯数据库打点员无论是在日常打点仍是对象引用的时辰，都能够在最短的时刻内找到自己所需要的对象。
　　要求五：尽量只存储单一实体类型的数据。
　　这宿将的实体类型跟数据类型不是一回事，要注重区分。这里讲的实体类型是指所需要描述对象的自己。笔者举一个例子，估量巨匠就可以年夜白其中的内容了。如斯刻有一个藏书楼里系统，有图书根基信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在统一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如斯设计的话，会给后续的维护带来不少的麻烦。
　　如当后续有图书出书时，则需要窝殴畚出书的图书增添作者信息，这无疑会增添额外的存储空间，也会增添记实的长度。而且若作者的情形有所改变，如住址改变了往后，则还需要去更改每本书的记实。同时，若这个作者的图书年夜数据库中全数删除之后，这个作者的信息也就荡然无存了。很较着，这不合适数据库设计规范化的需求。
　　碰着这种情形时，笔者建议可以把膳缦沔这张表分化成三种自力的表，分袂为图书根基信息表、作者根基信息表、图书与作者对应表等等。如斯设计往后，以上碰着的所有问题就都引刃而解了。
　　以上五条是在数据库设计时达到规范化水平的根基要求。除了这些此外还有良多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有手艺方面的严酷限制，首要依靠数据库打点员日常工作经验的累积。