数据库建设规范.doc

数据库建设规范目录1. 前言22. 范围23. 术语和定义23.1范式23.2关联33.3关系模型33.4视图33.5外键33.6约束33.7主键34. 命名规范44.1规范约定44.2表名44.3视图44.4存储过程44.5函数44.6触发器44.7字段54.8索引55. 数据库建设过程规范55.1概述55.2需求分析阶段65.2.1需求调查65.2.2内容分析65.3概念结构设计阶段75.2.1定义实体75.3.3定义关系75.3.4定义属性75.3.5定义键85.3.6定义索引85.3.7定义其他对象和规则95.4逻辑结构设计阶段95.5数据库物理设计阶段105.6实施、运行、维护规范106. 数据库建设安全性规范116.1概述116.2完整性设计116.3物理安全136.4访问控制136.5数据备份14 1. 前言数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。本规范通过数据建库的命名、结构、建库过程及安全性措施等几个技术方面进行约定，目的就是提供一套规范、合理、科学的建库技术体系，应用系统提供建库技术参考。2. 范围本规范主要从关系数据库的命名、关系和结构以及建设过程等几个方面来规定数据库设计应遵循的规范。3. 术语和定义3.1范式关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称 1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。3.2关联关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。3.3关系模型关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在关系模型中，实体与实体间的联系都是用关系来表示的。3.4视图视图是一个定制的虚拟表。可以是本地的、远程的或带参数的；其数据可以来源于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以更新数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。3.5外键外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的或其它的）关系中的主键。它是关系之间的逻辑链接。3.6约束数据库管理系统必须提供一种机制来检查数据库中的数据，看其是否满足语义规定的条件，这些加在数据库数据之上的语义规范，称为约束。约束又可以分为完整性约束、唯一性约束等。3.7主键每张表都应该包含相同的一个或一组字段，它们都是保存在表中的、每一条记录的唯一标识，通常这些字段（即主键）需要在建立数据表时就设定并标记。4. 命名规范4.1规范约定命名采用 26个英文字母（一律大写）和 09这十个自然数，加上下划线“_”组成，共 63个字符，不能出现其他字符（注释除外）。数据库对象包括表、视图、存储过程、函数、触发器、字段、数据库文档。对象名字由前缀和实体名称组成，长度不超过 30个字符。前缀描述对象类型，实体名称包括系统标识等信息尽量详尽描述实体的内容，不以数字或下划线开头，对象名称中的标识用下划线“_”进行分隔。其中“”内的内容表示是可选内容。4.2表名T_ _ 如：T_NPCP_ORDER4.3视图V_ _ _ 如：V_NPCP_ORDER4.4存储过程P_ _如：P_NPCP_ORDER_ADD4.5函数F_ _ _如：F_NPCP_ORDER_ADD4.6触发器TR_ _ _如：TR_NPCP_ORDER_ADD4.7字段_ _如：ORDER_ID4.8索引IN_ _如：IN_NPCP_ORDER_NAME 5. 数据库建设过程规范5.1概述建库过程建议参考以下的建库流程如图 1所示。需求分析阶段综合各科学数据用户的应用需求，形成规范的需求调查表、需求规格书、功能需求表。概念设计阶段形成独立于机器特点、独立于各个数据库管理系统产品的概念模式，用 E-R图来描述。逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图形成数据的外模式。数据可以分为两大类：关系数据和非关系数据，在物理设计阶段根据数据库管理系统的特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。最后进行数据（或元数据）录入。建库过程的每一步都是对其前一步骤的检验，对于发现的错误或偏差需要进行及时的评估，并进行修正完善。对由于数据库的设计而在应用当中的造成的不良影响及出现数据误差等现象进行修缮、更新、完善。图 1数据库建设过程5.2需求分析阶段需求分析阶段可以分为两个步骤：需求调查和内容分析。数据大概分为两类数据：关系型数据和非关系型数据（如文件，文档）。在需求分析阶段可以对这两种数据进行不同的处理和分析。5.2.1需求调查数据信息来源有以下几种方法，分析系统需求分析报告书，组织调查会，咨询业务专家。非关系型数据要分析哪几类类型，如文件的格式。5.2.2内容分析需求收集和分析，结果得到数据字典描述的数据需求，数据流图描述的处理需求。数据项数据项含义数据类型长度取值范围可选性注释表1 数据字典规范模式图2 数据流图的表达方式5.3概念结构设计阶段这个阶段的任务确定建模目标，开发建模计划，组织建模队伍，收集数据资源，制定约束和规范。5.2.1定义实体找出潜在的实体，形成初步实体表，然后再进行必要的调整。满足下述两条准则的事物，一般均可作为属性对待。（1）作为“属性”，不能再具有需要描述的性质。 “属性”必须是不可分的数据项，不能包含其他属性。（2）“属性”不能与其他实体具有联系，即 ER图中所表示的联系是实体之问的联系。5.3.3定义关系模型中只允许二元联系，n元联系必须定义为 n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。即在这一步工作中确定任意有关联的两个实体之间的关系类型。5.3.4定义属性从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主键属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主键属性必须依赖于主键、整个主键、仅仅是主键。5.3.5定义键通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选键属性，以便唯一识别每个实体的实例，再从侯选键中确定主键。为了确定主键和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出 IDEF1X模型的键基视图，确定关系中的主键和外键等。键选择规范：1)键设计原则：为关联字段创建外键;所有的键都必须唯一;避免使用复合键;外键总是关联唯一的键字段。2)使用系统生成的主键,设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。3)不要采用用户可编辑的字段作键(不让主键具有可更新性)在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。4)可选键有时可做主键,把可选键进一步用做主键，可以拥有建立强大索引的能力。5.3.6定义索引索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）；2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引；3）如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引；4）逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。5)大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。6)不要索引 MEMO(备注)字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。7)不要索引常用的小型表。不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。5.3.7定义其他对象和规则定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。最后形成的概念模型用 E-R图进行表示。5.4逻辑结构设计阶段将概念结构转换为某个数据库管理系统所支持的数据模型（例如关系模型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的数据库管理系统，形成数据库文档。将 E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式。关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的。所以将 E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式，这种转换要遵循如下规范原则：1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的标识对应关系模型的候选码。2）一个 m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系模型的候选码为各实体标识的组合。3）一个 1:n联系可以转换为一个独立的关系模式，也可以与 n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的标识 以及联系本身的属性均转换为关系的属性，而关系的码为 n端实体的码。4）一个 1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的标识以及联系本身的属性均转换为关系的属性。而关系模型的候选码为各实体码的组合。6）同一实体集的实体间的联系，即自联系，也可按上述 1:1、1:n和 m:n三种情况分别处理。7）具有相同码的关系模式可合并。为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为 3NF的标准，即：表内的每一个值都只能被表达一次。表内的每一行都应该被唯一的标识（有唯一键）。表内不应该存储依赖于其他键的非键信息。对所有的快捷方式、命名规范、限制和函数都要编制文档。采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。对数据库文档化，或者在数据库自身的内部或者单独建立文档。为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的 Rational Rose，CA公司Erwin和Bpwin，Sybase公司的owerDesigner以及 Oracle公司的 Oracle Designer等。设计人员可根据需要选用相应的数据库设计建模工具。5.5数据库物理设计阶段数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。评价物理数据库的方法完全依赖于所选用的数据库管理系统，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。规范规定，物理设计当中在遵循数据库设计范式的基础之上，规定科学数据库建库时除数据库设计所遵循的范式外的一些适用规范：1) 所有数据记录都要有 ID序列字段，ID号由数据库自动生成，以标识记录。2) 所有记录都要有“更新时间”字段，记录标识数据更新情况。3) 对于主-明细表结构，设计对应的视图将两表连接用于查询。4) 可以取消主外键关联，通过对应的程序来维护数据一致性。5) 类别和状态的多选：多选分为必选（1.n）和可选（0.n）。如是必选，在设计时要有说明，在程序实现中应有控制和检查。两个可选的类别或状态表可以合并为一个表，再与引用此表的主表形成多对多的关系。5.6实施、运行、维护规范运用数据库管理系统提供的数据语言（例如 SQL）及其宿主语言（例如JAVA），根据逻辑设计和物理设计的结果建科学数据库，编制与调试应用程序，组织科学数据入库，并进行试运行。规范规定：SQL关键词全部大写，比如SELECT,UPDATE,FROM,ORDER,BY等。数据库实施主要包括以下工作：用 DDL定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行。建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。所有的sql语句要最进性能分析，和压力测试。并且需要提交测试报告。数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改，定期提交运行监测报告。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。 6. 数据库建设安全性规范6.1概述随着数据库技术的不断进步，信息安全问题也日益突出，数据库的安全性也更加受到重视。建设科学数据库中，很多科学数据都是不可再现的，甚至是长期积累获得的成果，失不可得，因此科学数据的安全性显得尤为重要。安全策略主要是维护科学数据信息的完整性、保密性和可用性。科学数据库的安全建设规范主要是物理安全、访问控制、数据备份等。同其它数据资源相同，科学数据库数据的安全威胁主要来自三个方面：非人为破坏，比如地震等；人为的非主动破坏，比如误操作；人为主动破坏，比如黑客入侵。对于非人为破坏，主要只能依靠定期备份或者热备份等，并在相隔物理距离外保护备份。本规范主要讨论对于人为破坏的安全性规范。6.2完整性设计1）完整性实现机制：实体完整性：每个数据实体都要有主键，即每条数据记录都要有唯一标识以区分不同记录。父表中插入数据：父表中插入数据，要看有哪些受限条件，以及注意插入父表数据时还有没有其他的辅助数据输入。如添加化学品数据基本信息时，要注意其成分信息的添加和关联。父表中更新数据：同样需要注意级联更新和受限条件的更新。用户定义完整性：数据字段的可选性（是否非空）以及数据检查等。2）用约束强制数据完整性完整性约束条件作用的对象可以是关系、元组、列三种。其中列约束主要是列的类型、取值范围、精度、排序等约束条件。元组的约束是元组中各个字段间的联系的约束。关系的约束是若干元组间、关系集合上以及关系之间的联系的约束。完整性约束条件涉及的这三类对象，其状态可以是静态的，也可以是动态的。（1）静态列级约束静态列级约束是对一个列的取值域的说明，这是最常用也最容易实现的一类完整性约束，包括以下几方面：l对数据类型的约束（包括数据的类型、长度、单位、精度等）。l对数据格式的约束。l对取值范围或取值集合的约束。l对空值的约束,空值表示未定义或未知的值，它与零值和空格不同。有的列允许空值，有的则不允许。l其他约束,例如关于列的排序说明，组合列等。（2）静态元组约束一个元组是由若干个列值组成的，静态元组约束就是规定元组的各个列之间的约束关系。例如订货关系中包含发货量、订货量等列，规定发货量不得超过订货量；又如教师关系中包含职称、工资等列，规定教授的工资不低于 1000元（3）静态关系约束在一个关系的各个元组之间或者若干关系之间常常存在各种联系或约束。常见的静态关系约束有：l实体完整性约束和参照完整性约束：实体完整性约束和参照完整性约束是关系模型的两个极其重要的约束，称为关系的两个不变性。l函数依赖约束。大部分函数依赖约束都在关系模式中定义。l统计约束。即字段值与关系中多个元组的统计值之间的约束关系。例如规定部门经理的工资不得高于本部门职工平均工资的 5倍，不得低于本部门职工平均工资的 2倍。这里，本部门职工的平均工资是一个统计值。（4）动态列级约束动态列级约束是修改列定义或列值时应满足的约束条件；包括下面两方面：修改列定义时的约束，例如，将允许空值的列改为不允许空值时，如果该列目前已存在空值，则拒绝这种修改。修改列值时的约束,修改列值有时需要参照其旧值，并且新旧值之间需要满足某种约束条件。例如，职工工资调整不得低于其原来工资，学生年龄只能增长等。（5）动态元组约束动态元组约束是指修改元组的值时元组中各个字段间需要满足某种约束条件。例如职工工资调整时新工资不得低于原工资工龄*1.5等。（6）动态关系约束动态关系约束是加在关系变化前后状态上的限制条件，例如事务一致性、原子性等约束条件。3）强制指示完整性在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。4）使用查找控制数据完整性控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。5）采用视图在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做会在处理数据库变更时提供了更多的自由。6.3物理安全保证物理安全是安全防范的基本。这主要是指保证数据库服务器、数据库所在环境、相关网络的物理安全性。比如：是否能够保证服务器所在网络的网线、交换机性能环境的物理安全；是否只有数据库管理员能够在物理上接触数据库服务器；是否能够确保避免通过社会工程学的手段来欺骗或者诱导从而能获得物理上的访问能力等等。6.4访问控制访问控制是基本安全性的核心。数据库系统的访问控制也包括了帐号管理、密码策略、权限控制、用户认证等方面，主要是从与帐号相关的方面来维护数据库的安全性。访问控制策略主要包括：避免帐号被人列举。比如，非管理员获得所有数据库用户帐号列表。最小化权限原则。数据库管理员仅仅分配帐号的足够使用权限。比如，如果一个用户只需要进行数据库的查询工作，那么这个用户使用的权限就只能局限于 SELECT语句，而不能有 DELETE、UPDATE等语句的使用权限。权限的扩散以及超越应用范围的访问是访问控制的一大威胁,很多科