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

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

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

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

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

所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为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.1NF

1NF是关系模型的最低要求，它的规则是：

每一列必须是原子的，不能分成多个子列。

每一行和列的位置只能有一个值。

不能具有多值列。

例：如果要求一个学生一行，一个学生可选多门课，则下面的“学生”表就不满足1NF：student(s－no,s－name,class－no)

其中：s－no为学号，s－name为学生姓名，class－no为课程号。因为一个学生可选多门课，所以列class－no有多个值，所以空不符合1NF。

规范化就是把它分成如下两个表：“学生”表和“选课”表，则这两个表就都满足1NF了。

student(s－no,s－name)

stu－class(s－no,class－no)

1.3.2NF

对于满足2NF的表，除满足1NF外，非主码的列必须依赖于所有的主码，而不是组合主码的一部分。如果满足1NF的表的主码只有一列，则它自动满足2NF。例：下面的“选课”表，不符合2NF。

stu－class(s－no,class－no,class－name)

其中：class－name为课程名称。因为词表的主码是：(s－no,class－no),非主码列class－name依赖于组合主码的一部分class－no,所以它不符合2NF。

对该表规范化也是把它分解成两个表：“选课”表和“课程”表，则它们就都满足2NF了。

stu－class(s－no,class－no)

class(class－no,class－name)

1.4.3NF

3NF的规则是除满足2NF 外，任一非主码列不能依赖于其它非主码列。例：下面的“课程”表，不符合3NF。

class(class－no,class－name,teacher－no,teacher－name)

其中：teacher－no为任课教师号，teacher－name为任课教师姓名。因为非主码列teacher－name依赖于另一非主码列teacher－no,所以它不符合3NF。其解决办法也是把它分解成两个表：“课程”表和“教师”表，则它们就都满足3NF了。

class(class－no,class－name,teacher－no)

teacher(teacher－no,teacher－name)

1.5.小结

当一个表是规范的，则其非主码列依赖于主码列。从关系模型的角度来看，表满足3NF最符合标准，这样的设计容易维护。一个完全规范化的设计并不总能生成最优的性能，因此通常是先按照3NF设计，如果有性能问题，再通过反规范来解决。

数据库中的数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度，但是对完全规范的数据库查询，通常需要更多的连接操作，从而影响查询的速度。因此，有时为了提高某些查询或应用的性能而破坏规范规则，即反规范。

2.数据的反规范

2.1.反规范的好处

是否规范化的程度越高越好?这要根据需要来决定，因为“分离”越深，产生的关系越多，关系过多，连接操作越频繁，而连接操作是最费时间的，特别对以查询为主的数据库应用来说，频繁的连接会影响查询速度。所以，关系有时故意保留成非规范化的，或者规范化以后又反规范了，这样做通常是为了改进性能。例如帐户系统中的“帐户”表B－TB01，它的列busi－balance(企业帐户的总余额)就违反规范，其中的值可以通过下面的查询获得：

select busi－code,sum(acc－balance)

from B－TB06

group by busi－code

如果B－TB01中没有该列，若想获得busi－name(企业名称)和企业帐户的总余额，

则需要做连接操作：

select busi－name,sum(acc－balance)

from B－TB01,B－TB06

where B－TB01.busi－code=B－TB06.busi－code

group by busi－code

如果经常做这种查询，则就有必要在B－TB01中加入列busi－balance，相应的代价则是必须在表B－TB06上创建增、删、改的触发器来维护B－TB01表上busi－balance列的值。类似的情况在决策支持系统中经常发生。

反规范的好处是降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，相应带来的问题是可能出现数据的完整性问题。加快查询速度，但会降低修改速度。因此决定做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点，好的索引和其它方法经常能够解决性能问题，而不必采用反规范这种方法。

2.2.常用的反规范技术

在进行反规范操作之前，要充分考虑数据的存取需求、常用表的大小、一些特殊的计算(例如合计)、数据的物理存储位置等。常用的反规范技术有增加冗余列、增加派生列、重新组表和分割表。

2.2.1.增加冗余列

增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如前面例子中，如果经常检索一门课的任课教师姓名，则需要做class和teacher表的连接查询：

select class－name,teacher－name

from class,teacher

where class.teacher－no=teacher.teacher－no

这样的话就可以在class表中增加一列teacher－name就不需要连接操作了。

增加冗余列可以在查询时避免连接操作，但它需要更多的磁盘空间，同时增加表维护的工作量。

2.2.2.增加派生列

增加派生列指增加的列来自其它表中的数据，由它们计算生成。它的作用是在查询

时减少连接操作，避免使用集函数。例如前面所讲的账户系统中的表B－TB01的列busi－balance就是派生列。派生列也具有与冗余列同样的缺点。

2.2.

3.重新组表

重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。例如，用户经常需要同时查看课程号，课程名称，任课教师号，任课教师姓名，则可把表class(class－no,class－name,teacher－no)和表teacher(teacher－no,teacher－name)合并成一个表class(class－no,class－name,teacher－no,teacher－name)。这样可提高性能，但需要更多的磁盘空间，同时也损失了数据在概念上的独立性。

2.2.4.分割表

有时对表做分割可以提高性能。表分割有两种方式：

1水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用:A 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。B 表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。

C 需要把数据存放到多个介质上。例如法规表law就可以分成两个表active－law和inactive－law。activea－authors表中的内容是正生效的法规，是经常使用的，而inactive－law 表则使已经作废的法规，不常被查询。水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要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）

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：

8实验八 数据库的完整性

实验八实现数据完整性一、实验目的 （1）实现数据完整性的概念及实施数据完整性的重要性。 （2）掌握数据完整性的分类。 （3）掌握完整性约束的添加、删除方法。 （4）掌握通用默认值的创建、实施与删除方法。 （5）掌握规则的创建、实施与删除方法。 （6）掌握级联删除、级联修改方法。 二、实验内容 1、完整性约束的添加、删除 （1）通过SQL Server Management Studio实施约束 a.为表Student的Birth字段创建检查约束，使输入的生日日期小于系统日期。 ①、选择Student表，右击→设计，打开Student表 ②、选择Birth一行，右击→CHECK约束，打开界面如下图所示 ③、单击“添加” ④、在表达式中写入：Entrance_date

b.为表Student的Sdept字段，设置默认值约束，默认值取’计算机系’。选择Sdept一行，在其列属性中修改其默认值 c.为Student表的Sname字段添加唯一性约束。 选择Sname一行，右击→索引/键 出现如下界面：

单击“添加”，在类型中选择“唯一键”，在列中选择“Sname”，名称自定义 最后单击“关闭”退出

d.将SC表的Sno,cno字段设置外键约束，约束名自已取，并允许级联删除与级联更新。（此要求在SQL Server2008R2中无法做出）若已存在外键约束，请先删除。 ①、选中Sno，右击→单击“关系”，出现如下信息，可见已存在外键约束 选中键，点击删除，完成约束删除 ②、添加约束： 选中Sno，右击，选择“关系”，出现如下信息，

数据库设计规范范本

数据库设计规范

1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常见的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。能够用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。能够用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或

者经过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。能够用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者经过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容易地理解。

软件工程-数据库设计规范与命名规则

数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:

规范化-数据库设计原则

规范化－数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。 序言 本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。 要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章1. 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 规范化实例 为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。 首先，我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)

数据库完整性

大连海事大学 数据库原理课程实验大纲 实验名称：实验七完整性实验学时： 2 适用专业： 实验环境： 执笔者：编写日期： 1实验目的 （1）掌握实体完整性、参照完整性和用户自定义完整性约束的创建方法。 （2）掌握完整性约束的运行检查机制。 （3）掌握参照完整性的级联删除和修改方法。 （4）掌握正确设计关系模式完整性约束的方法。 2实验内容 2.1掌握实体完整性约束的创建和使用方法 （1）创建表时定义由一个属性组成的主键（给约束命名）。 （2）创建表时定义由两个或两个以上属性组成的主键（给约束命名）。 （3）删除以上两个主键约束。 （4）利用ALTER TABLE语句定义上述两个主键。 2.2掌握参照完整性约束的创建和使用方法 （5）创建表时定义一个列级参照完整性约束（给约束命名）。 （6）创建表时定义一个表级的由两个属性组成的参照完整性约束（给约束命名）。（7）设计数据更新语句检查参照完整性约束是否起作用。

（8）删除上述完整性约束。 （9）利用ALTER TABLE 建立上述参照完整性约束，并且规定UPDATE/DELETE时的动作。 （10）设计数据更新语句检查参照完整性约束及其相应的动作是否起作用。 2.3掌握用户自定完整性约束的创建和使用方法 （11）定义一个检查约束，检查其值在某个取值范围内，并设计相应的更新语句检查该约束是否起作用 （12）定义一个检查其值符合某个匹配模式的检查约束（使用LIKE），并设计相应的更新语句检查该约束是否起作用 （13）定义一个检查其值符合某个正则表达式的检查约束（使用SIMILAR TO），并设计相应的更新语句检查该约束是否起作用 （14）定义一个UNIQUE约束，并设计相应的更新语句检查该约束是否起作用 （15）定义一个DEFAULT约束，设计一个INSERT语句检查该约束是否起作用。 3实验要求 （1）深入复习教材第五章数据库完整性约束内容。 （2）根据书上的例子，针对TPCH数据库模式设计各种完整性约束，每种类型完整性约束至少要设计一个，描述清楚完整性约束要求，设计和运行触发完整性约束检查的数据更新语句，并截图相应的实验结果，每幅截图并要有较为详细的描述。也可以按照附1所列示例做实验。（3）实验步骤和实验总结中要详细描述实验过程中出现的问题、原因和解决方法。 （4）思考题：完整性约束的违约处理有哪几种方式 4实验步骤 4.1掌握实体完整性约束的创建和使用方法 （1）创建表时定义由一个属性组成的主键（给约束命名）。

数据库表及字段命名、设计规范

数据库表及字段命名、设计规范1、命名规范 1.1数据表的命名规范： 1）表的前缀应该用系统或模块的英文名的缩写（全部大写或首字母大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS)，那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表。 2）表的名称必须易于理解，使用能表达表功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 3）表的名称一般使用名词或者动宾短语 4）表名称不应该取得太长（一般不超过三个英文单词）。 5）在命名表时，用单数形式表示名称。例如，使用Employee，而不是Employees。 6）对于有主明细的表来说。明细表的名称为：主表的名称+ 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts 对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int 型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。 7）表必须填写描述信息

数据库的设计范式规范化

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。 范式说明 1.1 第一范式（1NF）无重复的列 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 例如，如下的数据库表是符合第一范式的： 而这样的数据库表是不符合第一范式的：

数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R 的某个候选键，则称为第二范式模式。 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。 简而言之，第二范式（2NF）就是非主属性完全依赖于主关键字。 所谓完全依赖是指不能存在仅依赖主关键字一部分的属性（设有函数依赖 W→A，若存在XW，有X→A成立，那么称W→A是局部依赖，否则就称W→A 是完全函数依赖）。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：

数据库设计规范

数据库设计规范 V 1.0 2007-8-28

目录 1) 目的 (3) 2) 范围 (3) 3) 术语 (3) 4) 设计概要 (3) 5) 命名规范（逻辑对象） (4) 6) 数据库对象命名 (6) 7) 脚本注释 (8) 8) 数据库操作原则 (9) 9) 常用字段命名(参考) (9)

1) 目的 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。 2) 范围 本规范适用于开发组全体人员，作用于软件项目开发的数据库设计、维护阶段。 3) 术语 数据库对象：在数据库软件开发中，数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。 物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。一般对数据库服务器物理设备的管理规程，在整个项目/产品的概要设计阶段予以规划。 逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。 4) 设计概要 ?设计环境 数据库：ORACLE 9i 、MS SQL SERVER 2000 等 操作系统：LINUX 7.1以上版本，显示图形操作界面; RedHat 9 以上版本 WINDOWS 2000 SERVER 以上 ?设计使用工具 使用PowerDesigner 做为数据库的设计工具，要求为主要字段做详尽说 明。对于SQL Server 尽量使用企业管理器对数据库进行设计，并且要求 对表，字段编写详细的说明（这些将作为扩展属性存入SQL Server中） 通过PowerDesigner 定制word格式报表，并导出word文档，作为数据 字典保存。（PowerDesigner v10 才具有定制导出word格式报表的功能）。

数据库表字段命名规范

数据库表字段命名规范 摘要：当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度 的问题，在后续开发使用原来数据库表时，也会因为数据库表的可读性不够高，表字段规则 不统一，造成数据查询，数据使用效率低的问题，所以有必要整理出一套合适的数据库表字 段命名规范来解决优化这些问题。 本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规 范文档，针对研发中易产生的问题和常见错误做了一个整理和修改，为日后涉及到数据库相 关的研发工作做好准备。 一、数据库命名规范 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线 '_'组成，命名简洁明确，多个单词用下划线'_'分隔，一个项目一个数据库，多 个项目慎用同一个数据库 二、数据库表命名规范 2.1数据表命名规范 （1）采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下 划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔 （2）全部小写命名，禁止出现大写 （3）禁止使用数据库关键字，如：name，time ，datetime，password等 （4）表名称不应该取得太长（一般不超过三个英文单词） （5）表的名称一般使用名词或者动宾短语 （6）用单数形式表示名称，例如，使用 employee，而不是 employees 明细表的名称为：主表的名称+字符dtl（detail缩写） 例如：采购定单的名称为：po_order，则采购定单的明细表为：po_orderdtl （7）表必须填写描述信息（使用SQL语句建表时）

2.2命名规范 ①模块_+功能点示例：alllive_log alllive_category ②功能点示例：live message ③通用表示例：all_user 2.3待优化命名示例 ①冗余： 错误示例：yy_alllive_video_recomment yy_alllive_open_close_log 说明：去除项目名，简化表名长度，去”yy_” ②相同类别表命名存在差异，管理性差 错误示例：yy_all_live_category yy_alllive_comment_user 说明：去除项目名，统一命名规则，均为”yy_alllive_”开头即可 ③命名格式存在差异 错误示例：yy_showfriend yy_user_getpoints yy_live_program_get 说明：去除项目名，统一命名规则，动宾短语分离且动宾逻辑顺序统一 三、数据库字段命名规范 3.1字段命名规范 （1）采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔 （2）全部小写命名，禁止出现大写 （3）字段必须填写描述信息 （4）禁止使用数据库关键字，如：name，time ，datetime password 等（5）字段名称一般采用名词或动宾短语 （6）采用字段的名称必须是易于理解，一般不超过三个英文单词 （7）在命名表的列时，不要重复表的名称

数据库实验报告完整性约束

数据库实验报告完整性约束

大连海事大学 数据库原理课程实验大纲 实验名称：实验七完整性实验学时： 2 适用专业：智能科学与技术 实验环境： Microsoft SQL server 2014 1实验目的 （1）掌握实体完整性、参照完整性和用户自定义完整性约束的创建方法。 （2）掌握完整性约束的运行检查机制。 （3）掌握参照完整性的级联删除和修改方法。（4）掌握正确设计关系模式完整性约束的方法。 2实验内容 2.1 掌握实体完整性约束的创建和使用方法 （1）创建表时定义由一个属性组成的主键（给约束命名）。 （2）创建表时定义由两个或两个以上属性组成的主键（给约束命名）。 （3）删除以上两个主键约束。 （4）利用ALTER TABLE语句定义上述两个主键。

2.2 掌握参照完整性约束的创建和使用方法 （5）创建表时定义一个列级参照完整性约束（给约束命名）。 （6）创建表时定义一个表级的由两个属性组成的参照完整性约束（给约束命名）。 （7）设计数据更新语句检查参照完整性约束是否起作用。 （8）删除上述完整性约束。 （9）利用ALTER TABLE 建立上述参照完整性约束，并且规定UPDATE/DELETE时的动作。（10）设计数据更新语句检查参照完整性约束及其相应的动作是否起作用。 2.3 掌握用户自定完整性约束的创建和使用方法 （11）定义一个检查约束，检查其值在某个取值范围内，并设计相应的更新语句检查该约束是否起作用？ （12）定义一个检查其值符合某个匹配模式的检查约束（使用LIKE），并设计相应的更新语句检查该约束是否起作用？ （13）定义一个检查其值符合某个正则表达式的检查约束（使用SIMILAR TO），并设计相应的更新语句检查该约束是否起作用？

数据库命名规范(表、字段名)

数据库命名规范（表、字段名） 一. 实体和属性的命名 1常用单词已经进行了缩写，在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种，所以要求加上下划线 举例： 定义的缩写Sales: Sal 销售； Order: Ord 订单； Detail: Dtl 明细； 则销售订单名细表命名为：Sal_Ord_Dtl; 2.如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。举例： 定义的缩写Material Ma 物品； 物品表名为：Material, 而不是Ma. 但是字段物品编码则是：Ma_ID;而不是Material」。 3.所有的存储值列表的表前面加上前缀Z 目的是将这些值列表类排序在数据库最后。 4.所有的冗余类的命名（主要是累计表）前面加上前缀X 冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段。或者表 5.关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名，后面按照字母顺序罗列两个表名或者表名的缩写。 关联表用于保存多对多关系。 如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建 议都使用缩写。 举例：表Object与自身存在多对多的关系，则保存多对多关系的表命名为：R_Object ； 表Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp 6.每一个表都将有一个自动ID作为主健，逻辑上的主健作为第一组候选主健来定义，如果是数据库自动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID” 的方法命名。 举例：销售订单的编号字段命名：Sal_Ord」D ;如果还存在一个数据库生成的自动编号，则 命名为：ID。

数据库设计规范

1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系 (Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可

以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容

数据库命名规范(表、字段名)

数据库命名规范（表、字段名） 一．实体和属性的命名 1．常用单词已经进行了缩写，在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种，所以要求加上下划线 举例： 定义的缩写 Sales: Sal 销售； Order: Ord 订单； Detail: Dtl 明细； 则销售订单名细表命名为：Sal_Ord_Dtl; 2．如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。 一、【操作规范】 1. 如无备注，则表中的第一个id字段一定是主键且为自动增长； 2. 如无备注，则数值类型的字段请使用UNSIGNED属性； 3. 如无备注，排序字段order_id在程序中默认使用降序排列； 4. 如无备注，所有字段都设置NOT NULL，并设置默认值； 5. 如无备注，所有的布尔值字段，如is_hot、is_deleted，都必须设置一个默认值，并设为0； 6. 所有的数字类型字段，都必须设置一个默认值，并设为0； 7. 针对varchar类型字段的程序处理，请验证用户输入，不要超出其预设的长度； 8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注中(“PK、自动增长”不用写)； 9. 如无说明，建表时一律采用innodb引擎； 二、【常用表名约定】 0. 说明：表前缀用项目名称首字母缩写；所以表名都小写，单词之间用下划线分开，单

词都用单数形式 1. user –用户 2. category –分类 3. goods –商品、产品等一切可交易网站的物品都用此命名 4. good_gallery –物品的相册 5. good_cate –物品的分类，除了单独作为表名，其他地方分类单词一律用缩写cate 4. attr –属性 5. article –文章、新闻、帮助中心等以文章形式出现的，一般都用此命名 6. cart –购物车 7. feedback –用户反馈 8. order –订单 9. site_nav –包括页头和页尾导航 10. site_config –系统配置表 11. admin –后台用户【RBAC标准表】 12. role –后台用户角色【RBAC标准表】 13. access –后台操作权限，相当于action【RBAC标准表】 14. role_admin –后台用户对应的角色【RBAC标准表】 15. access_role –后台角色对应的权限【RBAC标准表】 16. 待续 三、【常用列名约定】 1. 表名_id –通常用作外键命名 2. cid –特殊的编号，带有元数据，方便关联查询，你可以把它理解成类别(层次)编号。举个例子，产品在分类时，往往需要将其归类到子分类下，相应的字段中也一般只记录子分类的id，这时若需要知道该产品属于哪个主分类，就需要通过子分类信息再查询到主分类信息，这是比较麻烦的，cid字段就是要解决这个问题。一般的站点几十个分类肯

ERP数据库设计方法、规范、技巧.

一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求,在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型,用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1.需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求。需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典 (Data Dictionary,简称DD来描述。

数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2.概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。

Greenplum数据库设计开发规范

G r e e n p l u m数据库设 计开发规范 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-

目录

第一章前言 1.1文档目的 随着Greenplum数据库的正式上线使用。为了保证Greenplum 数据仓库系统平台的平稳运行，保证系统的可靠性、稳定性、可维护性和高性能。特制定本开发规范，以规范基于Greenplum数据库平台的相关应用开发，提高开发质量。 1.2预期读者 Greenplum数据仓库平台应用的设计与开发人员； Greenplum 数据仓库平台的系统管理人员和数据库管理员； Greenplum 数据仓库平台的运行维护人员； 1.3参考资料 参考Greenplum4.3.x版本官方指引： 《GPDB43AdminGuide.pdf》 《GPDB43RefGuide.pdf》 《GPDB43UtilityGuide.pdf》

第二章设计规范 2.1数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等，在Greenplum数据库中，系统元数据同时保存在Master 服务器和Segment 服务器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成系统运行逐步变慢；同时，类似数据库的备份、恢复、扩容等较大型的操作都导致效率变慢。因此，依据GreenplumDB产品的最佳时间，单个数据库的对象数量，应控制在10万以内。 GP数据库的对象包括：表、视图、索引、分区子表、外部表等。 如果数据表的数量太多，建议按应用域进行分库，尽量将单个数据库的表数量控制在10万以内，可以在一个集群中创建多个数据库。 【备注】：在Greenplum数据库中，一张分区表，在数据库中存储为一张父表、每张分区子表都是一张独立的库表；例如：一张按月进行分区的存储一年数据的表，如果含默认分区，共14张表。 2.2表创建规范 为了避免数据库表数量太多，避免单个数据表的数据量过大，给系统的运行和使用带来困难，在Greenplum数据库中需遵循如下的表创建规范： 1、GP系统表中保存的表名称都是以小写保存。通常SQL语句中表名对大小写不敏感。但不允许在建表语句中使用双引号（“”）包括表

数据库设计规范

1概述 1.1 目的 软件研发数据库设计规范作为数据库设计的操作规范， 详细描述了数据库设计过程及结果，用于指导系统设计人员 正确理解和开展数据库设计。 1.2 适用范围 1.3 术语定义 DBMS：数据库管理系统，常用的商业 DBMS有 Oracle, SQL Server, DB2 等。 数据库设计：数据库设计是在给定的应用场景下，构造 适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体- 关系 (Entity-RelationShip, 简称 E-R) 理论为基础，并对这一理论进 行了扩充。它从用户的观点出发对信息进行建模，主要 用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用 Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产 品支持的数据模型，如关系模型，形成数据库逻辑模式。可

以用 Sybase PowerDesigner工具直接建立逻辑数据模型 （ LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用 Sybase PowerDesigner 工具直接建立物理数据模型（ PDM），或者通过 CDM / LDM 转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应 用系统的性能要求。 紧凑性：例如能用 char(10) 的就不要用 char(20) ，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容

数据库实验3

实验三：数据完整性 1、实验目的 （1）了解SQL Serer数据库系统中数据完整性控制的基本方法 （2）熟练掌握常用CREATE 或ALTER 在创建或修改表时设置约束 （3）了解触发器的机制和使用 （4）验证数据库系统数据完整性控制 2、实验平台 使用SQL Server数据库管理系统提供的SSMS和查询编辑器。 3 实验内容及要求 结合ST数据库中的各个表，设置相关的约束，要求包括主键约束、外键约束、唯一约束、检查约束、非空约束等，掌握各约束的定义方法。 设置一个触发器，实现学生选课总学分的完整性控制，了解触发器的工作机制。 设计一些示例数据，验证完整性检查机制。 要求包括如下方面的内容： 3.1 使用SQL语句设置约束 使用CREATE或ALTER语句完成如下的操作，包括： 1．设置各表的主键约束 2．设置相关表的外键 3. 设置相关属性的非空约束、默认值约束、唯一约束 4. 设置相关属性的CHECK约束 3.2 使用触发器 创建一个触发器，实现如下的完整性约束：

● 当向SC 表中插入一行数据时，自动将学分累加到总学分中。 ● 记录修改学分的操作。 3.4 检查约束和触发器 分别向相关表插入若干条记录，检查你设置的完整性约束是否有效： 1． 插入若干条包含正确数据的记录，检查插入情况 2． 分别针对设置的各个约束，插入违反约束的数据，检查操作能否进行 3． 向SC 表插入若干行数据，检查触发器能否实现其数据一致性功能。 ４ 实验报告 要求写出实验的基本过程。解释操作过程中出现的现象。 SC Student

参考示例： 建立一个学生选课数据库，熟悉约束及触发器的使用方法。 一、声明完整性约束 创建学生选课数据库TEST，包括三个基本表，其中Student表保存学生基本信息，Course 表保存课程信息，SC表保存学生选课信息，其结构如下表： 表1. Student表结构 表2. Course表结构 表3. SC表结构

数据库设计规范

- 茶马古道电子商务有限公司 数据库设计规范 V 1.0 版权所有

文档信息 作者： 创建日期（yyyy-mm-dd）: 审核者: 审核日期（yyyy-mm-dd）: 最后修订者： 最后修订日期（yyyy-mm-dd）: 文档类型： 文档修订历史 版本号修订日期修订者修订内容1.0.0 2011.9.20 金洋初始化

数据库约定 对应于XXXX MYSQL数据库环境的数据库类型定义如下表：1 Development Database 开发环境使用 开发环境数据库 2 Quality Assurance Database 质保环境使用 质保环境数据库 3 Production Database 生产环境使用 生产环境数据库 4 Training Database 培训环境使用 培训环境数据库 5 SIT Database 集成测试环境使用集成测试环境数据库 数据库字符集选择UTF8字符集 (建库时确定) 1. 数据库元素命名规范 长度约定：字段名，表名，视图名称等长度不能超过25个字符1.1. 表命名规范 数据类型数据类型（英文）前缀 主数据Master Data Table TM 业务事务处理数据Transaction Data Table TT 关系表Relationship Table TR 代码列表Code List Table TC 接口表Interface Table TI 系统管理表System administration Table TS 日志表Log Table TL 历史表History Table TH 中间临时表Temparory table TE 汇总表Aggregation Table TA 归档表Archivie Table TZ

数据库命名设计规范

数据库命名、设计规范 一、数据库表及字段 1．数据库表的命名规范： 表的前缀应该用系统或模块的英文名的缩写（全部大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表。 表的名称必须是易于理解，能表达表的功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 表名称不应该取得太长（一般不超过三个英文单词）。表名长度不能超过30个字符，表名中含有单词全部采用单数形式，单词首字母必须大写。在命名表时，用单数形式表示名称。例如，使用 Employee，而不是 Employees。对于有主明细的表来说。明细表的名称为：主表的名称 + 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts;对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。表必须填写描述信息，后台表名尽量与前台表名相同，后台独有的表应以_b作为后缀。如r_gggd_b。 数据库表的命名采用如下规则： 1)表名用模块名_开头，表名长度不能超过30个字符，表名中含有单词全部采用单数形式，单词首字母必须大写。 2)多个单词间用下划线（_）进行连接。若库中有多个系统，表名采用系统名称+单词或多个单词，系统名是开发系统的缩写，如VNET。