数据库设计标准规范化的五个要求.doc

数据库设计规范化五个要求通常情况下，能够从两个方面来判定数据库是否设计比较规范。一是看看是否拥有大量窄表，二是宽表数量是否足够少。若符合这两个条件，则能够说明这个数据库规范化水平还是比较高。当然这是两个泛泛而谈指标。为了达成数据库设计规范化要求，通常来说，需要符合以下五个要求。要求一：表中应该避免可为空列。即使表中许可空列，不过，空字段是一个比较特殊数据类型。数据库在处理时候，需要进行特殊处理。如此话，就会增加数据库处理统计复杂性。当表中有比较多空字段时，在相同条件下，数据库处理性能会降低很多。所以，即使在数据库表设计时候，许可表中含有空字段，不过，我们应该尽可能避免。若确实需要话，我们能够经过部分折中方法，来处理这些空字段，让其对数据库性能影响降低到最少。一是经过设置默认值形式，来避免空字段产生。如在一个人事管理系统中，有时候身份证号码字段可能许可为空。因为不是每个人全部能够记住自己身份证号码。而在职员报到时候，可能身份证没有带在身边。所以，身份证号码字段往往不能立即提供。为此，身份证号码字段能够许可为空，以满足这些特殊情况需要。不过，在数据库设计时候，则能够做部分处理。如当用户没有输入内容时候，则把这个字段默认值设置为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为前缀。如此数据库管理员不管是在日常管理还是对象引用时候，全部能够在最短时间内找到自己所需要对象。要求五：尽可能只存放单一实体类型数据。这里将实体类型跟数据类型不是一回事，要注意区分。这里讲实体类型是指所需要描述对象本身。笔者举一个例子，估量大家就能够明白其中内容了。如现在有一个图书馆里系统，有图书基础信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是能够。如能够把表设计成图书名字、图书作者等等。可是如此设计话，会给后续维护带来不少麻烦。如当后续有图书出版时，则需要为每次出版图书增加作者信息，这无疑会增加额外存放空间，也会增加统计长度。而且若作者情况有所改变，如住址改变了以后，则还需要去更改每本书统计。同时，若这个作者图书从数据库中全部删除以后，这个作者信息也就荡然无存了。很显著，这不符合数据库设计规范化需求。碰到这种情况时，笔者提议能够把上面这张表分解成三种独立表，分别为图书基础信息表、作者基础信息表、图书和作者对应表等等。如此设计以后，以上碰到全部问题就全部引刃而解了。以上五条是在数据库设计时达成规范化水平基础要求。除了这些另外还有很多细节方面要求，如数据类型、存放过程等等。而且，数据库规范往往没有技术方面严格限制，关键依靠数据库管理员日常工作经验累积。数据库设计中反规范技术探讨1. 数据库设计简述数据库设计是把现实世界商业模型和需求转换成数据库模型过程，它是建立数据库应用系统关键问题。设计关键是怎样使设计数据库能合理地存放用户数据，方便用户进行数据处理。数据库设计完全是人问题，而不是数据库管理系统问题。系统不管设计是好是坏，照样运行。数据库设计应该由数据库管理员和系统分析员一起和用户一道工作，了解各个用户要求，共同为整个数据库做出合适、完整设计。数据库及其应用性能和调优全部是建立在良好数据库设计基础上，数据库数据是一切操作基础，假如数据库设计不好，则其它一切调优方法提升数据库性能效果全部是有限。数据规范化1.1. 范式概述规范化理论是研究怎样将一个不好关系模式转化为好关系模式理论，规范化理论是围绕范式而建立。规范化理论认为，一个关系数据库中全部关系，全部应满足一定规范(约束条件)。规范化理论把关系应满足规范要求分为几级，满足最低要求一级叫做第一范式(1NF)，在第一范式基础上提出了第二范式(2NF)，在第二范式基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式等级越高，应满足约束集条件也越严格。规范每一等级全部依靠于它前一等级，比如若一个关系模式满足2NF，则一定满足1NF。下面我们只介绍1NF，2NF，3NF范式。1.2. 1NF1NF是关系模型最低要求，它规则是：每一列必需是原子，不能分成多个子列。每一行和列位置只能有一个值。不能含有多值列。例：假如要求一个学生一行，一个学生可选多门课，则下面“学生”表就不满足1NF： student(sno,sname,classno)其中：sno为学号，sname为学生姓名，classno为课程号。因为一个学生可选多门课，所以列classno有多个值，所以空不符合1NF。规范化就是把它分成以下两个表：“学生”表和“选课”表，则这两个表就全部满足1NF了。student(sno,sname) stuclass(sno,classno)1.3. 2NF对于满足2NF表，除满足 1NF外，非主码列必需依靠于全部主码，而不是组合主码一部分。假如满足1NF表主码只有一列，则它自动满足2NF。例：下面“选课”表，不符合2NF。 stuclass(sno,classno,classname)其中：classname为课程名称。因为词表主码是： (sno,classno),非主码列classname依靠于组合主码一部分classno,所以它不符合2NF。对该表规范化也是把它分解成两个表：“选课”表和“课程”表，则它们就全部满足2NF了。stuclass(sno,classno) class(classno,classname)1.4. 3NF3NF规则是除满足2NF 外，任一非主码列不能依靠于其它非主码列。 例：下面“课程”表，不符合3NF。class(classno,classname,teacherno,teachername)其中：teacherno为任课老师号，teachername为任课老师姓名。因为非主码列teachername依靠于另一非主码列teacherno,所以它不符合3NF。其处理措施也是把它分解成两个表：“课程”表和 “老师”表，则它们就全部满足3NF了。class(classno,classname,teacherno) teacher(teacherno,teachername)1.5. 小结当一个表是规范，则其非主码列依靠于主码列。从关系模型角度来看，表满足3NF最符合标准，这么设计轻易维护。一个完全规范化设计并不总能生成最优性能，所以通常是先根据3NF设计，假如有性能问题，再经过反规范来处理。数据库中数据规范化优点是降低了数据冗余，节省了存放空间，对应逻辑和物理I/O次数降低，同时加紧了增、删、改速度，不过对完全规范数据库查询，通常需要更多连接操作，从而影响查询速度。所以，有时为了提升一些查询或应用性能而破坏规范规则，即反规范。2. 数据反规范2.1. 反规范好处是否规范化程度越高越好?这要依据需要来决定，因为“分离”越深，产生关系越多，关系过多，连接操作越频繁，而连接操作是最费时间，尤其对以查询为主数据库应用来说，频繁连接会影响查询速度。所以，关系有时有意保留成非规范化，或规范化以后又反规范了，这么做通常是为了改善性能。比如帐户系统中“帐户”表BTB01，它列busibalance(企业帐户总余额)就违反规范，其中值能够经过下面查询取得：select busicode,sum(accbalance)from BTB06group by busicode假如BTB01中没有该列，若想取得businame(企业名称)和企业帐户总余额，则需要做连接操作：select businame,sum(accbalance)from BTB01,BTB06 where BTB01.busicode=BTB06.busicodegroup by busicode假如常常做这种查询，则就有必需在BTB01中加入列busibalance，对应代价则是必需在表BTB06上创建增、删、改触发器来维护BTB01表上busibalance列值。类似情况在决议支持系统中常常发生。反规范好处是降低连接操作需求、降低外码和索引数目，还可能降低表数目，对应带来问题是可能出现数据完整性问题。加紧查询速度，但会降低修改速度。所以决定做反规范时，一定要权衡利弊，仔细分析应用数据存取需求和实际性能特点，好索引和其它方法常常能够处理性能问题，而无须采取反规范这种方法。2.2. 常见反规范技术在进行反规范操作之前，要充足考虑数据存取需求、常见表大小、部分特殊计算(比如累计)、数据物理存放位置等。常见反规范技术有增加冗余列、增加派生列、重新组表和分割表。2.2.1.增加冗余列增加冗余列是指在多个表中含有相同列，它常见来在查询时避免连接操作。比如前面例子中，假如常常检索一门课任课老师姓名，则需要做class和teacher表连接查询：select classname,teachernamefrom class,teacherwhere class.teacherno=teacher.teacherno这么话就能够在class表中增加一列 teachername就不需要连接操作了。增加冗余列能够在查询时避免连接操作，但它需要更多磁盘空间，同时增加表维护工作量。2.2.2.增加派生列增加派生列指增加列来自其它表中数据，由它们计算生成。它作用是在查询时降低连接操作，避免使用集函数。比如前面所讲账户系统中表BTB01列 busibalance就是派生列。派生列也含有和冗余列一样缺点。2.2.3.重新组表重新组表指假如很多用户需要查看两个表连接出来结果数据，则把这两个表重新组成一个表来降低连接而提升性能。比如，用户常常需要同时查看课程号，课程名称，任课老师号，任课老师姓名，则可把表class(classno,classname,teacherno)和表 teacher(teacherno,teachername)合并成一个表 class(classno,classname,teacherno,teachername)。这么可提升性能，但需要更多磁盘空间，同时也损失了数据在概念上独立性。2.2.4.分割表有时对表做分割能够提升性能。表分割有两种方法：1水平分割：依据一列或多列数据值把数据行放到两个独立表中。 水平分割通常在下面情况下使用:A 表很大，分割后能够降低在查询时需要读数据和索引页数，同时也降低了索引层数，提升查询速度。B 表中数据原来就有独立性，比如表中分别统计各个地域数据或不一样时期数据，尤其是有些数据常见，而另外部分数据不常见。C 需要把数据存放到多个介质上。 比如法规表law就能够分成两个表activelaw和inactivelaw。activeaauthors表中内容是正生效法规，是常常使用，而inactivelaw表则使已经作废法规，不常被查询。水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询全部数据需要union操作。在很多数据库应用中，这种复杂性会超出它带来优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层磁盘次数。2垂直分割：把主码和部分列放到一个表，然后把主码和另外列放到另一个表中。假如一个表中一些列常见，而另外部分列不常见，则能够采取垂直分割，另外垂直分割能够使得数据行变小，一个数据页就能存放更多数据，在查询时就会降低I/O次数。其缺点是需要管理冗余列，查询全部数据需要join操作。3. 反规范技术需要维护数据完整性不管使用何种反规范技术，全部需要一定管理来维护数据完整性，常见方法是批处理维护、应用逻辑和触发器。批处理维护是指对复制列或派生列修改积累一定时间后，运行一批处理作业或存放过程对复制或派生列进行修改，这只能在对实时性要求不高情况下使用。数据完整性也可由应用逻辑来实现，这就要求必需在同一事务中对全部包含表进行增、删、改操作。用应用逻辑来实现数据完整性风险较大，因为同一逻辑必需在全部应用中使用和维护，轻易遗漏，尤其是在需求改变时，不易于维护。另一个方法就是使用触发器，对数据任何修改立即触发对复制列或派生列对应修改。触发器是实时，而且对应处理逻辑只在一个地方出现，易于维护。通常来说，是处理这类问题最好措施。4. 结束语数据库反规范设计能够提升查询性能。常见反规范技术有增加冗余列、增加派生列、重新组表和分割表。但反规范技术需要维护数据完整性。所以在做反规范时，一定要权衡利弊，仔细分析应用数据存取需求和实际性能特点。Oracle 数据库设计阶段性能优化策略经过对Oracle 数据库系统物理结构和逻辑结构分析，叙述了在Oralce数据库设计开发阶段性能优化部分策略和方法。Oracle是现在使用最为广泛大型数据库管理系统，提升Oracle数据库系统运行效率，是整个计算机信息系统高效运转前提和确保。影响Oracle数据库应用系统性能原因很多，现有软件方面原因，也包含数据运行硬件环境、网络环境、数据库管理和维护方面原因等。数据库系统设计开发阶段是Oracle应用优化最好阶段，也是主动优化阶段，能达成以最小成本取得最大性能增益目标。经过对其逻辑存放结构和物理存放结构设计进行优化，使之在满足需求条件下，时空开销性能最好，能够处理数据库系统运行过程中性能渐进性下降或性能突降等问题，以确保系统运行优良性能。Oracle数据库逻辑结构和物理结构Oracle 数据库逻辑结构是由部分数据库对象组成，如数据库表空间、表、索引、段、视图、存放过程、触发器等。数据库逻辑存放结构(表空间等)决定了数据库物理空间是怎样被使用，数据库对象如表、索引等分布在各个表空间中。Oracle 数据库物理结构从操作系统一级查看，是由一个个文件组成，从物理上可划分为：数据文件、日志文件、控制文件和参数文件。数据文件中存放了全部数据信息;日志文件存放数据库运行期间产生日志信息，它被反复覆盖使用，若不采取归档方法话，已被覆盖日志信息将无法恢复；控制文件统计了整个数据库关键结构信息，它若被破坏，整个数据库将无法工作和恢复；参数文件中设置了很多Oracle 数据库配置参数，当数据库开启时，会读取这些信息。逻辑结构优化逻辑结构优化用通俗话来说就是经过增加、降低或调整逻辑结构来提升应用效率，下面经过对基础表设计及索引、聚簇讨论来分析ORACLE逻辑结构优化。1、基础表扩展:数据库性能包含存放空间需求量大小和查询响应时间长短两个方面。为了优化数据库性能，需要对数据库中表进行规范化。通常来说，逻辑数据库设计满足第三范式表结构轻易维护且基础满足实际应用要求。所以，实际应用中通常全部根据第三范式标准进行规范化，从而确保了数据库一致性和完整性，设计人员往往会设计过多表间关联，以尽可能地降低数据冗余。但在实际应用中这种做法有时不利于系统运行性能优化:如过程从多表获取数据时引发大量连接操作，在需要部分数据时要扫描整个表等，这全部消耗了磁盘I/O 和CPU 时间。为处理这一问题，在设计表时应同时考虑对一些表进行反规范化，方法有以下多个：一是分割表。分割表可分为水平分割表和垂直分割表两种:水平分割是根据行将一个表分割为多个表，这能够提升每个表查询速度，但查询、更新时要选择不一样表，统计时要汇总多个表，所以应用程序会更复杂。垂直分割是对于一个列很多表，若一些列访问频率远远高于其它列，就能够将主键和这些列作为一个表，将主键和其它列作为另外一个表。经过降低列宽度，增加了每个数据页行数，一次I/O就能够扫描更多行，从而提升了访问每一个表速度。不过因为造成了多表连接，所以应该在同时查询或更新不一样分割表中列情况比较少情况下使用。二是保留冗余列。当两个或多个表在查询中常常需要连接时，能够在其中一个表上增加若干冗余列，以避免表之间连接过于频繁，通常在冗余列数据不常常变动情况下使用。三是增加派生列。派生列是由表中其它多个列计算所得，增加派生列能够降低统计运算，在数据汇总时能够大大缩短运算时间。所以，在数据库设计中，数据应该按两种类别进行组织：频繁访问数据和频繁修改数据。对于频繁访问不过不频繁修改数据，内部设计应该物理不规范化。对于频繁修改但并不频繁访问数据，内部设计应该物理规范化。有时还需将规范化表作为逻辑数据库设计基础，然后再依据整个应用系统需要，物理地非规范化数据。规范和反规范全部是建立在实际操作基础之上约束，脱离了实际二者全部没有意义。只有把二者合理地结合在一起，才能相互补充，发挥各自优点。2、索引和聚簇:创建索引是提升检索效率最有效方法之一，索引把表中逻辑值映射到安全 RowID，能快速定位数据物理地址，能够大大加紧数据库查询速度，一个建有合理索引数据库应用系统可能比一个没有建立索引数据库应用系统效率高几十倍，但并不是索引越多越好，在那些常常需要修改数据列上建立索引，将造成索引B*树不停重组，造成系统性能下降和存放空间浪费。对于一个大型表建立索引，有时并不能改善数据查询速度，反而会影响整个数据库性能。这关键是和SGA数据管理方法相关，Oracle在进行数据块高速缓存管理时，索引数据比一般数据含有更高驻留权限，在进行空间竞争时，Oracle会先移出一般数据，对建有索引大型表进行数据查询时，索引数据可能会用完全部数据块缓存空间，Oracle不得不频繁地进行磁盘读写来获取数据，所以，在对一个大型表进行分区以后，能够依据对应分区建立分区索引。Oracle提供了另一个方法来提升查询速度，就是聚簇(Cluster)。所谓聚簇，简单地说就是把多个表放在一起，按一定公共属性混合存放。聚簇依据共同码值将多个表数据存放在同一个Oracle块中，这时检索一组Oracle块就同时得到两个表数据，这么就能够降低需要存放Oracle块，从而提升应用程序性能。对于逻辑结构优化，还应将表数据和索引数据分开表空间存放，分别使用独立表空间。因为假如将表数据和索引数据放在一起，表数据I/O操作和索引I/O操作将产生影响系统性能I/O竞争，降低系统响应效率。将表数据和索引数据存放在不一样表空间中，并在物理层面将这两个表空间数据文件放在不一样物理磁盘上，就能够避免这种竞争了。物理结构优化数据库数据最终是存放在物理磁盘上，对数据进行访问就是对这些物理磁盘进行读写，所以对于这些物理存放优化是系统优化一个关键部分。对于物理存放结构优化，关键是合理地分配逻辑结构物理存放地址，这么虽不能降低对物理存放读写次数，但却能够使这些读写尽可能并行，降低磁盘读写竞争，从而提升效率，也能够经过对物理存放进行精密计算降低无须要物理存放结构扩充，从而提升系统利用率。1、磁盘读写并行优化:对于数据库物理读写，Oracle系统本身会进行尽可能并行优化，比如在一个最简单表检索操作中，假如表结构和检索域上索引不在一个物理结构上，那么在检索过程中，对索引检索和对表检索就是并行进行。2、操作并行优化:操作并行优化是基于操作语句统计结果，首先是统计各个表访问频率，表之间连接频率，依据这些数据按以下标准分配表空间和物理磁盘，降低系统进程和用户进程磁盘I/O竞争;把需要连接表格在表空间/物理磁盘上分开;把高频访问表格在表空间/物理磁盘上分开;把常常需要进行检索表格表结构和索引在表空间/物理磁盘上分开。3、降低存放结构扩展:假如应用系统数据库比较脆弱，并在不停地增加或缩小，这么系统在非动态改变周期内效率合理，不过当在动态改变周期内时候，性能却很差，这是因为Oracle动态扩展造成。在动态扩张过程中，Oracle必需依据存放要求，在创建行、行改变获取缺省值时，扩展和分配新存放空间，而且表格扩展往往并不是事情终止，还可能造成数据文件、表空间增加，这些扩展会造成在线系统反应缓慢。对于这么系统，最好措施就是在建立时候预先分配足够大小和适宜增加幅度。在一个对象建立时候要依据应用充足地计算她们大小，然后再依据这些数据来定义对象Initial、Next和Minextents值，使数据库在物理存放上和动态增加次数上达成一个比很好平衡点，使这些对象既不常常发生增加，也不过多地占用数据库。结论优化Oracle 数据库对提升计算机系统可用性和效率,含有很关键意义, 尤其是在Oracle数据库设计开发阶段，对逻辑结构和物理结构进行有效优化设计，创建一个计划布局合理数据库，能够取得最小系统开销，能从根本上大大提升应用系统整体性能，对于以后数据库性能调整和利用全部有很大益处。（T006）