TR-REC-031建库技术指导规范

1、o 3.2 3.2 关联 o 3.3 3.3 关系模型 o 3.4 3.4 视图 o 3.5 3.5 外键 o 3.6 3.6 约束 o 3.7 3.7 主键 4 4命名规范 o 4.1 4.1 规范约定 o 4.2 4.2 表名 o 4.3 4.3 视图 o 4.4 4.4 存储过程 o 4.5 4.5 函数 o 4.6 4.6 触发器 o 4.7 4.7 字段 o 4.8 4.8 索引 5 5数据库建设过程规范 o 5.1 5.1 概述 TR-REC-031建库技术指导规范（征求意 见稿） 出自标准规范协同工作环境 20100226 目录 隐藏 1 1前言 2 2范围 3 3术语和定义 o

2、 3.1 3.1 范式 o5.2 5.2需求分析阶段 521 5.2.1需求调杳 5.2.2 5.2.2内容分析 o5.3 5.3概念结构设计阶段 5.3.1 5.3.1准备工程 5.3.2 5.3.2定义实体 5.3.3 5.3.3定义关系 534 5.3.4 定义属性 5.3.5 5.3.5 定义键 5.3.6 5.3.6 定义索引 5.3.7 5.3.7 定义其他对象和规则 o 5.4 5.4逻辑结构设计阶段 o5.5 5.5数据库物理设计阶段 o5.6 5.6实施、运行、维护规范 6 6数据库建设安全性规范 o6.1 6.1概述 o6.2 6.2完整性设计 621 6.2.1完整性实现

3、机制 6.2.2 6.2.2用约束强制数据完整性 6.2.2.1 6.2.2.1 静态列级约束 6.2.2.2 6.2.2.2 静态元组约束 6.2.2.3 6.2.2.3 静态关系约束 6.2.2.4 6.2.2.4 动态列级约束 6.2.2.5 6.2.2.5 动态元组约束 6.2.2.6 6.2.2.6 动态关系约束 6.2.3 6.2.3强制指示完整性 6.2.4 6.2.4使用查找控制数据完整性 6.2.5 6.2.5采用视图 o 6.3 6.3物理安全 o 6.4 6.4访问控制 o 6.5 6.5数据备份 7附录1:需求调查表范例-水土保持与生态环境研究中心 8附录2:范式 9参

4、考文献 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用 环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足 用户信息要求和处理要求。 经过近几年的快速发展，科学数据库项目内开发了一批数据库应用项目， 但由于 没有规范性的建库指导，导致了部分数据库不能方便快捷的为外部提供服务；另 外，项目内还存在大量的科学数据有待整理， 因此为了更好的将科学数据对外提 供服务以及对各种纷繁复杂的数据进行整合， 构建规范的建库技术规范是必然也 是必需的。科学的数据库建库技术能够对已有的数据进行高效的保存利用，同时 促进科学研究的进一步发展，有利于发现、挖掘深层次的科学研

5、究成果。 本规范通过科学数据建库的命名、结构、建库过程及安全性措施等几个技术方面 进行约定，目的就是提供一套规范、合理、科学的建库技术体系，为科学数据的 应用系统提供建库技术参考， 提高科学数据的有效利用率和可整合性。 同时，本 规范期望能够为科学数据的研究人员和建库技术人员， 及科学数据的应用人员所 用，以便能够保证科学数据存储的规范性， 提高科学数据在信息领域的再利用率。 2 范围 本规范主要从关系数据库的命名、 关系和结构以及建设过程等几个方面来规定数 据库设计应遵循的规范。 本规范适用于科学数据库项目内或其他可应用的数据库建设领域， 主要用来规范 和指导科学数据库系统内各项目及单位的数

6、据库建库工作。 3 术语和定义 3.1 范式 关系数据库中的关系是要满足一定要求的， 满足不同程度要求的为不同范式。 满 足最低要求的叫第一范式，简称1NF在第一范式中满足进一步要求的为第二范 式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 3.2 关联 关联是不同表之间的数据彼此联系的方法。 关联同时存在于形成不同实体的数据 项之间和表实体本身之间， 构成了数据库规范化的基本核心问题。 它分为一对一、 一对多、多对多三种关联形式。 3.3 关系模型 关系模型由关系数据结构、 关系操作集合和关系完整性约束三部分组成。 在关系 模型中，实体与实体间的联系都是用关系来表示的。 3.4

7、 视图 视图是一个定制的虚拟表。 可以是本地的、远程的或带参数的； 其数据可以来源 于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以更新 数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。 3.5 外键 外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的或其 它的）关系中的主键。它是关系之间的逻辑链接。 3.6 约束 数据库管理系统必须提供一种机制来检查数据库中的数据， 看其是否满足语义规 定的条件， 这些加在数据库数据之上的语义规范， 称为约束。 约束又可以分为完 整性约束、唯一性约束等。 3.7 主键 每张表都应该包含相同的一个或一组字段， 它们

8、都是保存在表中的、 每一条记录 的唯一标识，通常这些字段（即主键）需要在建立数据表时就设定并标记。 4 命名规范 4.1 规范约定 命名采用 26 个英文字母（一律大写）和 09 这十个自然数，加上下划线“ _” 组成，共 63 个字符，不能出现其他字符（注释除外）。 数据库对象包括表、视图、存储过程、函数、触发器、字段、数据库文档。对象 名字由前缀和实体名称组成，长度不超过 30 个字符。前缀描述对象类型；实体 名称包括系统标识等信息尽量详尽描述实体的内容， 不以数字或下划线开头； 对 象名称中的标识用下划线“ _”进行分隔。其中“ ”内的内容表示是可选内容。 4.2 表名 TB_系统标识v

9、 ,. 表标识 例：植物信息管理系统中的植物信息表 TB_PMS_PLANTINFO 4.3 视图 VI_ v 系统标识 _v ,. _ v 视图标识 例：植物信息管理系统中的植物信息视图 VI_PMS_PLANTINFO 4.4 存储过程 SP_ _ 例：植物信息管理系统中的植物信息存储过程 SP_PMS_PLANTINFO 4.5 函数 FN_ _ _ 例：植物信息管理系统中的植物信息添加 FN_PLANTINFO_ADD 4.6 触发器 TR_ _ _ 例：植物信息管理系统中的植物添加 TR_PLANTINFO_ADD 4.7 字段 _ _ 例：植物信息管理系统中的植物信息表中的植物名称

10、字段 PLANTINFO_NAME 4.8 索引 IN_ _ 例：植物信息管理系统中的植物信息表中的植物名称索引 IN_PLANTINFO_NAME 5 数据库建设过程规范 5.1 概述 科学数据库技术建库过程建议参考以下的建库流程如图1 所示。数据库设计中需 求分析阶段综合各科学数据用户的应用需求 （包括存储科学数据和应用科学数据 的需要），形成规范的需求调查表、需求规格书、功能需求表，有可能还可以提 供著录范例； 在概念设计阶段形成独立于机器特点、 独立于各个数据库管理系统 产品的概念模式，用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据 库产品支持的数据模型如关系模型， 形成数

11、据库逻辑模式。 然后根据用户处理的 要求，安全性的考虑，在基本表的基础上再建立必要的视图形成数据的外模式。 由于科学数据库有其存储数据的特殊性， 把数据可以分为两大类： 关系数据和非 关系数据（包括不可关系存储的文档、观测数据），在物理设计阶段根据数据库 管理系统的特点和处理的需要， 进行物理存储安排， 设计索引， 形成数据库内模 式。最后进行数据（或元数据）录入。建库过程的每一步都是对其前一步骤的检 验，对于发现的错误或偏差需要进行及时的评估， 并进行修正完善。 对由于数据 库的设计而在应用当中的造成的不良影响及出现数据误差等现象进行修缮、更 新、完善。 5.2 需求分析阶段 在科学数据库建

12、库的需求分析阶段可以分为两个步骤： 需求调查和内容分析。 由 于科学数据信息的来源形式各异， 数据形态纷繁复杂， 不易统一管理， 我们可以 把科学数据大概分为两类数据： 关系型数据和非关系型数据 （不可关系化的数据， 如观测文档、 仪器文件等） 。在需求分析阶段可以对这两种数据进行不同的处理 和分析。 5.2.1 需求调查 科学数据信息来源常有的几种方法是：观测、试验、文献等。因此数据的调查分 析常用的调查方法有： 跟班观测和试验、开调查会、请专人（观测员、采集员 等）介绍询问、设计调查表请用户填写、查阅记录。总之，根据用户的需求和数 据的特性， 调查组织机构情况、 调查各科学操作流程、 协助

13、科研用户明确对新的 系统和数据库的各种要求、确定数据库方案的界定。 对于关系型的数据调查最后要形成需求调查表，包括需求介绍、数据表单、 范例著录、功能需求单。 对于非关系型的数据调查最后要形成需求调查表，包括需求介绍、元数据元 素需求单、著录范例和功能需求单，数据附录。 非关系型的数据需求调查表的填写范例见附录 1 522内容分析 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需 求）。需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理 要求、安全性与完整性要求。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的 结构化分析方法（Str

14、uctured Analysis，简称SA方法）从最上层的系统组织机 构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 系统中的数据借助数据字典（Data Dictionary ，简称DD来描述，如表1所示 （其中的数据项描述仅供参考）。通过数据字典能够切实的对数据进行真实准确 的描述。 表1数据字典规范模式 数据项 数据项含义 数据类型 长度 取值范围 可选性 注释 J ! J J J J J J J J J J J ! J J J J J J J J J J J ! J J J J J J J J J J 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即

15、元数据，而 不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理 过程五个部分。其中数据项是数据的最小组成单位， 若干个数据项可以组成一个 数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的 逻辑内容。 数据项是不可再分的数据单位。对数据项的描述通常包括以下内容： 数据项描述=数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系 其中“取值范围”、“与其他数据项的逻辑关系”（例如该数据项等于另几个数 据项的和，该数据项值等于另一数据项的值等）定义了数据的完整性约束条件， 是设计数据检验功能的依据。本规范规定至少应该包

16、含每个字段的数据类型和在 每个表内的主外键，另外在数据结构当中应该设置数据项的ID号和数据更新时 间字段为必备字段。 数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成， 也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。 对数据 结构的描述通常包括以下内容： 数据结构描述=数据结构名，含义说明，组成：数据项或数据结构 数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容： 数据流描述=数据流名，说明，数据流来源，数据流去向， 组成：数据结构，平均流量，高峰期流量 其中“数据流来源”是说明该数据流来自哪个过程。 “数据流去向”是说明该数 据流将到哪

17、个过程去。 “平均流量”是指在单位时间（每天、每周、每月等）里 的传输次数。“高峰期流量”则是指在高峰时期的数据流量。 数据存储是数据结构停留或保存的地方， 也是数据流的来源和去向之一。 它可以 是手工文档或手工凭单， 也可以是计算机文档。 对数据存储的描述通常包括以下 内容： 数据存储描述=数据存储名，说明，编号，流入的数据流，流出的数据流， 组成：数据结构,数据量，存取方式 其中“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息。 “存取方式”包括是批处理还是联机处理； 是检索还是更新； 是顺序检索还是随 机检索等。另外， “输入的数据流”要指出其来源，“输出的数据流”要指出

18、其 去向。 处理过程的具体处理逻辑一般用判定表或判定树来描述。 数据字典中只需要描述 处理过程的说明性信息，通常包括以下内容： 处理过程描述=处理过程名，说明，输入：数据流，输出：数据流, 处理：简要说明 其中“简要说明” 中主要说明该处理过程的功能及处理要求。 功能是指该处理过 程用来做什么（而不是怎么做），处理要求包括处理频度要求，如单位时间里处 理多少事务、多少数据量、 响应时间要求等。 这些处理要求是后面物理设计的输 入及性能评价的标准。 数据流图（Data Flow Diagram，简称DFD是描述数据流和当数据从输入移动 到输出时被应用变换的图形化技术， 它以数据传递和加工的角度，

19、 以图型的方式 刻画数据的运动情况。 对于比较复杂的实际问题，在数据流图上常常出现十几个乃至几十个“加工”， 这样的数据流图看起来很不清晰， 规范规定采用层次结构的数据流图来解决这一 问题。 仅用此图是不能表明数据加工要求的，需要进一步细化。如果S可以分解成两个 子加工S1、S2,则可以画出它们加工及其相关数据流，子系统 S1又可以细化为 S1.1、S1.2 等等。 明确地把需求收集和分析作为数据库设计的第一阶段是十分重要的。这一阶段收 集到的基础数据（用数据宇典来表达）和一组数据流程图是下一步进行概念设计 的基础。 5.3概念结构设计阶段 通过对科学数据用户需求进行综合、归纳与抽象，形成一个

20、独立于具体数据库管 理系统的概念模型，可以用 E-R图（实体一关系图）表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个数据库管理系统支持的 数据模型。概念模型可以转换为计算机上某一数据库管理系统支持的特定数据模 型。 概念模型特点： 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流 的语言。 概念模型设计常用的方法，它就是把实体-关系方法应用到语义数据模型中的一 种语义模型化技术，用于建立系统信息模型。 下面以植物信息管理系统局部关系为例，介绍创建 E-R模型的步骤如下所示： 5.3.1准备工程 这个

21、阶段的任务是从科学研究的目的描述和范围描述开始，确定建模目标，开发 建模计划，组织建模队伍，收集数据资源，制定约束和规范。通过调查和观察结 果，科学数据应用流程，原有管理系统的输入输出，收集原始数据，形成基本科 学数据表，如在植物学的研究过程中获得的植物信息数据表。 5.3.2定义实体 事实上，在现实世界中具体的应用环境常常对实体和属性己经作了大体的自然的 划分。在数据字典中，“数据结构”、“数据流”和“数据存储”都是若干属性 有意义的聚合，就体现了这种划分。可以根据源数据名字表中表示物的术语以及 具有“代码”结尾的术语，如植物代码、分布地区代码、植物种类代码等将其名 词部分代表的实体标识出来

22、，从而初步找出潜在的实体，形成初步实体表，然后 再进行必要的调整。在调整中遵循的一条原则是：为了简化 ER 图的处置，现 实世界的事物能作为属性对待的，尽量作为属性对待。 那么符合什么条件的事物可以作为属性对待呢？本来， 实体与属性之间并没有形 式上可以截然划分的界限，但可以给出两条准则： 1. 作为“属性”，不能再具有需要描述的性质。 “属性”必须是不可分的数 据项，不能包含其他属性。 2. “属性”不能与其他实体具有联系，即 ER 图中所表示的联系是实体之 问的联系。 凡满足上述两条准则的事物，一般均可作为属性对待。 5.3.3 定义关系 模型中只允许二元联系， n 元联系必须定义为 n

23、个二元联系。根据实际的业务需 求和规则， 使用实体联系矩阵来标识实体间的二元关系， 然后根据实际情况确定 出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强 制的或可选的） 还是非确定关系、 分类关系。 如果子实体的每个实例都需要通过 和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如 果每个子实体的实例都与而且只与一个父实体关联， 则为强制的， 否则为非强制 的。如果父实体与子实体代表的是同一现实对象， 那么它们为分类关系。 即在这 一步工作中确定任意有关联的两个实体之间的关系类型。 如植物名称实体是其植 物分类代码实体的实例， 某一特殊植物物种在统一

24、的分类体系下只能属于一个分 类，而同一分类可能存在多种植物物种。 5.3.4 定义属性 从源数据表中抽取说明性的名词开发出属性表， 确定属性的所有者。 定义非主键 属性，检查属性的非空及非多值规则。 此外，还要检查完全依赖函数规则和非传 递依赖规则，保证一个非主键属性必须依赖于主键、整个主键、仅仅是主键。 5.3.5 定义键 通过引入交叉实体除去上一阶段产生的非确定关系， 然后从非交叉实体和独立实 体开始标识侯选键属性， 以便唯一识别每个实体的实例， 再从侯选键中确定主键。 为了确定主键和关系的有效性， 通过非空规则和非多值规则来保证， 即一个实体 实例的一个属性不能是空值， 也不能在同一个时

25、刻有一个以上的值。 找出误认的 确定关系，将实体进一步分解，最后构造出 IDEF1X模型的键基视图。确定关系 中的主键和外键等， 如植物中文名称可以作为植物基本信息的主键， 同时与植物 特性实体关联时又可作为特性实体的外键。 键选择规范： 1. 键设计原则 #为关联字段创建外键。 所有的键都必须唯一。 避免使用复合键。 外键总是关联唯一的键字段。 2. 使用系统生成的主键 设计数据库的时候采用系统生成的键作为主键， 那么实际控制了数据库的 索引完整性。 这样，数据库和非人工机制就有效地控制了对存储数据中每 一行的访问。 采用系统生成键作为主键还有一个优点： 当拥有一致的键结 构时，找到逻辑缺陷

26、很容易。 3. 不要采用用户可编辑的字段作键 （ 不让主键具有可更新性 ） 在确定采用什么字段作为表的键的时候， 可一定要小心用户将要编辑的字 段。通常的情况下不要选择用户可编辑的字段作为键。 4. 可选键有时可做主键 把可选键进一步用做主键，可以拥有建立强大索引的能力。 5.3.6 定义索引 索引是从数据库中获取数据的最高效方式之一。 95%的数据库性能问题都可以采 用索引技术得到解决。 1. 如果一个（或一组） 属性经常在查询条件中出现， 则考虑在这个 （或这组） 属性上建立索引（或组合索引）； 2. 如果一个属性经常作为最大值和最小值等聚集函数的参数， 则考虑在这个 属性上建立索引； 3

27、. 如果一个（或一组） 属性经常在连接操作的连接条件中出现， 则考虑在这 个（或这组）属性上建立索引； 4. 逻辑主键使用唯一的成组索引， 对系统键 （作为存储过程） 采用唯一的非 成组索引， 对任何外键列采用非成组索引。 考虑数据库的空间有多大， 表 如何进行访问，还有这些访问是否主要用作读写。 5. 大多数数据库都索引自动创建的主键字段， 但是可别忘了索引外键， 它们 也是经常使用的键， 比如运行查询显示主表和所有关联表的某条记录就用 得上。 6. 不要索引MEM（备注）字段，不要索引大型字段（有很多字符），这样作 会让索引占用太多的存储空间。 7. 不要索引常用的小型表。 不要为小型数据

28、表设置任何键， 假如它们经常有 插入和删除操作就更别这样作了。 对这些插入和删除操作的索引维护可能 比扫描表空间消耗更多的时间。 5.3.7 定义其他对象和规则 定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、 存储过程、视图、角色、同义词、序列等对象信息。 最后形成的概念模型用 E-R 图进行表示。 5.4 逻辑结构设计阶段 将概念结构转换为某个科学数据库管理系统所支持的数据模型 （例如关系模型） ， 并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据 模型，然后选择最合适的科学数据库管理系统，形成数据库文档。 一定要花点时间创建 E-R 图表和数据

29、字典。其中至少应该包含每个字段的数据 类型和在每个表内的主外键。创建 E-R 图表和数据字典确实有点费时但对其他 开发人员要了解整个设计却是完全必要的。 越早创建越能有助于避免今后可能面 临的混乱，从而可以让任何了解和应用数据库的人都明确如何从数据库中获得数 据。 将 E-R 图转换为关系模型实际上就是要将实体、 实体的属性和实体之间的联系转 化为关系模式。 关系模型的逻辑结构是一组关系模式的集合。 E-R 图则是由实 体、实体的属性和实体之间的联系三个要素组成的。 所以将 E-R 图转换为关系模 型实际上就是要将实体、 实体的属性和实体之间的联系转换为关系模式， 这种转 换要遵循如下规范原则

30、： 1. 一个实体型转换为一个关系模式。 实体的属性就是关系的属性。 实体的标 识对应关系模型的候选码。 2. 一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系 本身的属性均转换为关系的属性。 而关系模型的候选码为各实体标识的组 合。 3. 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系 模式合并。 如果转换为一个独立的关系模式， 则与该联系相连的各实体的 标识以及联系本身的属性均转换为关系的属性， 而关系的码为 n 端实体的 码。 4. 一个 1:1 联系可以转换为一个独立的关系模式， 也可以与任意一端对应的 关系模式合并。 5. 三个或三个以上实体间的

31、一个多元联系转换为一个关系模式。 与该多元联 系相连的各实体的标识以及联系本身的属性均转换为关系的属性。 而关系 模型的候选码为各实体码的组合。 6. 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三 种情况分别处理。 7. 具有相同码的关系模式可合并。 为了进一步提高数据库应用系统的性能， 通常以规范化理论为指导， 还应该适当 地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗 余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分 解。一般来说将关系分解为3NF的标准，即： 表内的每一个值都只能被表达一次。 表内的每一行都应该被唯一

32、的标识（有唯一键）。 表内不应该存储依赖于其他键的非键信息。 对所有的快捷方式、命名规范、限制和函数都要编制文档。采用给表、列、触发 器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。对数据库文档化, 或者在数据库自身的内部或者单独建立文档。 规范规定： 逻辑结构设计的成果体现在数据库文档中，数据库文档应该包括以下的内容： *以模块形式表达的设计文档，大致如表 2所示。 表2模块形式的设计文档 表名：tb_Pms_Pla nti nfo 建表人：xiao nao_2008 建表日期：2008-05-23 版本：1.0 描述：植物信息管理系统的植物信息表 辅助应用数据字典描述数据表，表例如

33、表 1所示 关系模型，表与表之间的关系以 E-R图形式表示，图例如图2所示。 为加快数据库设计速度，目前有很多数据库辅助工具（CASET具），如Rational 公司的 Rational Rose,CA公司的 Erwin 和 Bpwin,Sybase公司的 PowerDesigner 以及 Oracle 公司的 Oracle Designer 等。 设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后， 设计人员可以使用UML画ER图，将ER图转换为关系数据模型，生成数据库结构； 画数据流图，生成应用程序。 5.5数据库物理设计阶段 为逻辑数据模型选取一个最适合应用环境的物理结

34、构（包括存储结构和存取方 法）。根据科学研究和科学数据应用系统特点和处理的需要，进行物理存储安排， 设计索引，形成科学数据库内模式。 科学数据库的物理设计与普通数据库的物理设计相同，通常分为两步： *确定数据库的物理结构 对物理结构进行评价，评价的重点是时间和空间效率 物理结构依赖于给定的科学数据库管理系统和硬件系统，因此设计人员必须充分 了解所用数据库管理系统的内部特征， 特别是存储结构和存取方法；充分了解应 用环境，特别是应用的处理频率和响应时间要求；并充分了解外存设备的特性。 数据库物理设计过程中需要对时间效率、 空间效率、维护代价和各种用户要求进 行权衡，其结果可以产生多种方案，数据库

35、设计人员必须对这些方案进行细致的 评价，从中选择一个较优的方案作为数据库的物理结构。 评价物理数据库的方法完全依赖于所选用的数据库管理系统，主要是从定量估算 各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较， 选择出一个较优的合理的物理结构。 如果该结构不符合用户需求，则需要修改设 计。 规范规定，物理设计当中在遵循数据库设计范式的基础之上， 规定科学数据库建 库时除数据库设计所遵循的范式外的一些适用规范： 1. 所有科学数据记录都要有ID序列字段，ID号由数据库自动生成，以标识 记录。 2. 所有科学数据记录都要有“更新时间”字段，记录标识数据更新情况。 3. 基本信息表

36、中应设置“编码”、“字段名”、“中文名称”，“编码”作 为主键与其它表的外键形成对应关系，完成基于主-外键的完整性约束。 另定义字段时都要提供相应的字段描述信息，增强其可读性。 4. 对于主-明细表结构，设计对应的视图将两表连接用于查询。 5. 类别和状态的多选：多选分为必选（1.n ）和可选（0.n ）。如是必选, 在设计时要有说明，在程序实现中应有控制和检查。两个可选的类别或状 态表可以合并为一个表，再与引用此表的主表形成多对多的关系。 5.6实施、运行、维护规范 运用数据库管理系统提供的数据语言（例如 SQL及其宿主语言（例如JAVA ， 根据逻辑设计和物理设计的结果建科学数据库， 编制

37、与调试应用程序，组织科学 数据入库，并进行试运行。 规范规定：SQL关键词全部大写，比如 SELECT,UPDATE,FROM,ORDE 等BY 数据库实施主要包括以下工作：用 DDL定义数据库结构、组织数据入库 、编制 与调试应用程序、数据库试运行。建立或者修订数据库之后，必须用用户新输入 的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的 数据类型满足应用要求，尤其在特殊的科学数据库当中，如植物物种数据库，根 据不同的需求提供不同的服务，如有些药用价值，经济价值等属性需要根据应用 需求进行取舍。测试需要在把新数据库投入实际服务之前完成， 并且需要提交测 试报告。 数据库

38、应用系统经过试运行后即可投入正式运行。 在数据库系统运行过程中必须 不断地对其进行评价、调整与修改，定期提交运行监测报告。包括：数据库的转 储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数 据库的重组织和重构造。 6 数据库建设安全性规范 6.1 概述 随着数据库技术的不断进步， 信息安全问题也日益突出， 数据库的安全性也更加 受到重视。 建设科学数据库中， 很多科学数据都是不可再现的， 甚至是长期积累 获得的成果， 失不可得，因此科学数据的安全性显得尤为重要。 安全策略主要是 维护科学数据信息的完整性、 保密性和可用性。 科学数据库的安全建设规范主要 是物理安全、访问控

39、制、数据备份等。 同其它数据资源相同， 科学数据库数据的安全威胁主要来自三个方面： 非人为破 坏，比如地震等；人为的非主动破坏，比如误操作；人为主动破坏，比如黑客入 侵。对于非人为破坏， 主要只能依靠定期备份或者热备份等， 并在相隔物理距离 外保护备份。本规范主要讨论对于人为破坏的安全性规范。 6.2 完整性设计 6.2.1 完整性实现机制 实体完整性： 每个数据实体都要有主键， 即每条数据记录都要有唯一标识以区分 不同记录。如定义植物物种的中文名称为主键以保证其完整性。 表中删除数据：删除数据的时候要注意主表删除时其附表应该同时进行删除。 父表中插入数据： 父表中插入数据， 要看有哪些受限条

40、件， 以及注意插入父表数 据时还有没有其他的辅助数据输入。 如添加化学品数据基本信息时， 要注意其成 分信息的添加和关联。 父表中更新数据：同样需要注意级联更新和受限条件的更新。 用户定义完整性：数据字段的可选性（是否非空）以及数据检查等。 6.2.2 用约束强制数据完整性 完整性约束条件作用的对象可以是关系、 元组、列三种。 其中列约束主要是列的 类型、取值范围、精度、排序等约束条件。元组的约束是元组中各个字段间的联 系的约束。关系的约束是若干元组间、关系集合上以及关系之间的联系的约束。 完整性约束条件涉及的这三类对象，其状态可以是静态的，也可以是动态的。 622.1 静态列级约束 静态列级

41、约束是对一个列的取值域的说明，这是最常用也最容易实现的一类完整 性约束，包括以下几方面： 对数据类型的约束（包括数据的类型、长度、单位、精度等） 例如，中国人民大学数据库中学生姓名的数据类型规定为字符型， 长度为 &中央民族大学数据库中学生姓名的数据类型规定为字符型， 长度为20， 因为少数民族的姓名较长。 对数据格式的约束 例如，规定学号的前两位表示入学年份，中间两位表示系的编号，后三位 为顺序编号。出生日期的格式为 YY MM DD *对取值范围或取值集合的约束 例如，规定学生成绩的取值范围为 0100，大学本科学生年龄的取值范 围为14- 29,性别的取值集合为男，女 对空值的约束 空值

42、表示未定义或未知的值，它与零值和空格不同。有的列允许空值，有 的则不允许。例如学生学号不能取空值，成绩可以为空值。 *其他约束 例如关于列的排序说明，组合列等。 6.2.2.2 静态元组约束 一个元组是由若干个列值组成的，静态元组约束就是规定元组的各个列之间的约 束关系。例如订货关系中包含发货量、订货量等列，规定发货量不得超过订货量； 又如教师关系中包含职称、工资等列，规定教授的工资不低于 1000元。 6.2.2.3 静态关系约束 在一个关系的各个兀组之间或者若干关系之间常常存在各种联系或约束。常见的 静态关系约束有： *实体完整性约束。 参照完整性约束。 实体完整性约束和参照完整性约束是关

43、系模型的两个极其重要的约束，称 为关系的两个不变性。 函数依赖约束。大部分函数依赖约束都在关系模式中定义。 统计约束。即字段值与关系中多个元组的统计值之间的约束关系。 例如规定部门经理的工资不得高于本部门职工平均工资的5倍，不得低于 本部门职工平均工资的2倍。这里，本部门职工的平均工资是一个统计值。 6.2.2.4 动态列级约束 动态列级约束是修改列定义或列值时应满足的约束条件；包括下面两方面: 修改列定义时的约束 例如，将允许空值的列改为不允许空值时， 如果该列目前已存在空值，则 拒绝这种修改。 修改列值时的约束 修改列值有时需要参照其旧值，并且新旧值之间需要满足某种约束条件。 例如，职工工

44、资调整不得低于其原来工资，学生年龄只能增长等。 622.5 动态元组约束 动态元组约束是指修改元组的值时元组中各个字段间需要满足某种约束条件。例 如职工工资调整时新工资不得低于原工资+工龄 *1.5等。 6.2.2.6 动态关系约束 动态关系约束是加在关系变化前后状态上的限制条件，例如事务一致性、原子性 等约束条件。 6.2.3强制指示完整性 在有害数据进入数据库之前将其剔除。 激活数据库系统的指示完整性特性。 这样 可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。 6.2.4使用查找控制数据完整性 控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户 一个清晰

45、的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据 的一致性。某些公共数据特别适合查找：国家代码、状态代码等。 6.2.5采用视图 在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图 而不必非要应用程序直接访问数据表。这样做会在处理数据库变更时提供了更多 的自由。 6.3物理安全 保证物理安全是安全防范的基本。这主要是指保证数据库服务器、数据库所在环 境、相关网络的物理安全性。比如：是否能够保证服务器所在网络的网线、交换 机性能环境的物理安全；是否只有数据库管理员能够在物理上接触数据库服务 器；是否能够确保避免通过社会工程学的手段来欺骗或者诱导从而能获得物理上 的访问能力等等。 6.4访问控制 访问控制是基本安全性的核心。科学数据库系统的访问控制也包括了帐号管理、 密码策略、权限控制、用户认证等方面，主要是从与帐号相关的方面来维护数据 库的安全性。比如：Spida蠕虫仅仅利用了 SQL Server数据库的最高管理员帐 号sa密码为空而入侵并扩散的。 访问控制策略主要包括： 避免帐号被人列举。比如，非管理员获得所有数据库用户帐号列表