修订历史记录
发放范围：产品研发部
1. 概述
2. 数据库设计的基本原则 3. 数据库建模
3.1 数据分析
3.2 数据关系分析 3.3 数据量分析 3.4 扩展性分析
3.5
数据字典（参考） 3.5.1 数据项 3.5.2 数据结构 3.5.3 数据流 3.5.4 数据存储 3.5.5 处理过程 3.6 E-R 图
3.7 分析描述工具 4. 数据库对象设计
4.1
表的设计原则 4.1.1 命名规则
4.1.2 公用包的命名规则4.1.3 表说明 4.2
字段设计原则 4.2.1 命名规则 4.2.2 字段说明
4.2.3 字段的一致性 4.2.4 建议字段
4.2.5 日期时间字段 4.2.6 数字和文本字段 4.3
键和索引
4.3.1 命名规则 4.3.2 键设计原则
4.4
视图设计原则（参考） 4.4.1 命名规则 4.4.2 视图说明 4.5
物化视图
4.5.1 命名规则
4.5.2 物化视图说明 4.6
触发器
4.6.1 命名规则 4.6.2 触发器说明 4.7
临时表设计原则 4.7.1 命名规则 4.7.2 临时表说明
目录
5 6 7 7 7 7 7 7 7 7 7 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 11 11 11 11 11 11 11 11 11 12
4.8
有效组织数据库对象 4.8.1 存储过程分包存储 4.9 包设计原则
4.9.1 命名规则 4.9.2 包说明 4.10 存储过程设计原则（参考）
4.10.1 命名规则 4.11 函数设计原则（参考）
4.11.1 命名规则 5. 数据完整性设计（参考）
5.1 完整性实现机制
5.2 用约束而非商务规则强制数据完整性 5.3 强制指示完整性
5.4 使用查找控制数据完整性 5.5
采用视图
6. 数据库安全性设计
6.1 保证数据的完整性 6.2 保证数据可恢复性 6.3
其他安全原则
7. 数据库的物理实现
7.1
数据库的选择
7.1.1 数据库和版本的选择 7.1.2 其他数据库和版本比较 7.1.3 数据库版权 7.2 数据库运行环境
7.2.1 数据库硬件配置
7.2.2 数据库运行操作系统和版本 7.2.3 数据库运行操作系统的版权 7.3 数据库应用环境的物理结构（参考）
7.3.1 存储结构设计 7.3.2 数据存放位置 7.3.3 存取方法设计
7.4 数据库性能和测试方法（参考）
7.4.1 数据库性能 7.4.2 测试方法 8. 数据库的管理
8.1 数据库管理员
8.2 数据库导入、导出 8.3 数据库备份、恢复 8.4 数据库记录清除 8.5
数据库维护
9. 数据库的升级
9.1
数据库升级方式
12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 14 14 14 14 15 15 15 15 15 15 15 16 16 16 16 16 16 17 17 17 18 18 18 18 18 18 19 19
附录
9.2
20 20 20 20 20 20 20
附录一 数据库设计文档说明 9.2.1 命名规则
9.2.2 数据库表创建文本 9.2.3 全部应用SQL 语句列表
9.2.4 数据库设计文档必须有版本号 9.3 附录二 数据库设计说明书评审表
数据库设计标准（产品部）
1.
概述
本文档是数据库设计执行标准，其所涉及的内容是数据库设计部分，不包括应用程序中数据库访问实现。
2. 数据库设计的基本原则
数据库设计三个范式规定;
第一范式（1NF ）：不存在多值字段
第二范式（2NF ）：非主键字段依赖于主键的整体 第三范式（3NF ）：非主键字段只依赖于主键
3.
3.1
数据库建模
数据分析
根据项目的《需求分析》列出全部数据，包括： 1) 输入数据：原始数据。
2) 输出数据：用户需要检索的数据，包括原始数据和派生的数据。
3.2 数据关系分析
1) 数据分类：根据应用将数据表分类。 2) 类关系：表之间的相互关系。
3) 数据关系：表之间字段之间的关系。
3.3 数据量分析
1) 数据量分析：最大可能的记录数量。适当考虑记录信息的备份、过期删除等。 2) 数据流量分析：结合于用户需求的单位时间可能进出的数据量分析。 3) 响应速度分析：为满足用户需求的响应速度分析。
3.4 扩展性分析
1) 在项目《需求分析》的基础上，充分考虑用户未来可能的需求，在设计上为这种需求保留余地
和可能的更改措施。
2) 注意考虑的内容是“结构”性的，而不是“内容”性的。
3.5 数据字典（参考）
3.5.1 数据项
1) 2) 3) 4) 5) 6) 7) 8)
数据项名
数据项含义说明 别名
数据类型 长度
取值范围 取值含义
与其他数据项的逻辑关系
3.5.2 数据结构
1) 数据结构名 2) 含义说明
3) 组成：数据项或数据结构
3.5.3 数据流
1) 2) 3) 4) 5) 6) 7)
数据流名 说明
数据流来源 数据流去向 组成：数据结构 平均流量 高峰期流量
3.5.4 数据存储
1) 2) 3) 4) 5) 6) 7) 8)
数据存储名 说明 编号
流入的数据流 流出的数据流 组成：数据结构 数据量 存取方式
3.5.5 处理过程
1) 2) 3) 4) 5)
3.6
处理过程名 说明
输入：数据流 输出：数据流 处理：简要说明
E-R 图
1) E-R 图也即实体-关系图(Entity Relationship Diagram)，提供了表示实体型、属性和关系的
方法，用来描述现实世界的概念模型。 2) 要遵循E-R 的设计规范， 例如：
实体（Entity ）：用矩形表示 属性(Attribute)：用椭圆形表示
关系(Relationship)：用菱形表示，菱形框内写明关系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1 : 1，1 : n或m : n）。
3.7 分析描述工具
1) 统一使用PowerDesign 。
2) 使用PowerDesign 生成报表工具生成文档
4.
4.1
数据库对象设计
表的设计原则
4.1.1 命名规则
1) 2) 3) 4)
只允许使用英文字母“A-Z ”、数字“0-9”和符号“_”。 全部大写，不允许大小写混合。
格式“[应用名] [_类型名]_表单词1[_表单词2]”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开，如“T_USER_MESSAGE”。
5) 不允许使用描述不明确的字母或数字。 6) 长度限制在20字节内。
7) 表示表名称的单词限定为2个。
4.1.2 公用包的命名规则
1） 础公用包相关表，命名以SY_开头
2） 业务公用包相关表，以业务名_开头，业务名原则上不长于4个字符，例：SHOP_ (商城,
4.1.3 表说明
每个表需要中文说明，该说明最终放到数据库中。 1) 版本标记
增加一个版本表，或在同类表中增加一个版本字段，用于说明当前数据库的版本。 2) 尽量不要使用数据库特殊功能
不要过多的依赖后台数据库系统软件的某些特殊功能。
4.2
字段设计原则
4.2.1 命名规则
1) 只允许使用英文字母“A-Z ”、数字“0-9”和符号“_”。 2) 格式：单词1[_单词2][_单词3]
3) 尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开，如
“USER_TYPE”，不建议使用汉语拼音。 4) 不允许使用描述不明确的字母或数字。 5) 字段名长度限制在20字节内。 6) 表示字段名称的单词限定为3个。
4.2.2 字段说明
如果数据库允许的话，每个字段需要附加中文名称或简短说明，该说明最终放到数据库中。
4.2.3 字段的一致性
相同属性的字段，要保证在各个表中的一致。 1) 名称一致。 2) 类型一致。 3) 长度一致。
4.2.4 建议字段
1) 主键：每个表必须提供主键，可以采用UUID （32位字符串）或SEQUENCE 来作为主键，建议一
般项目用UUID ，便于维护，“XXX_ID”。
2) 创建时间：添加记录的当前时间。名称统一为“CREATE_TIME”。“日期时间”类型；默认当
前时间；
3) 删除标记：使用删除标志，而不是直接删除记录。名称统一为“DELETE_SIGN”。布尔型；默
认为“false ”；如果是oracle 数据库则使用NUMBER(1)来存储0/1。
4) 最后变更时间，具体看实际应用决定是否添加。如需考虑操作日志相关信息，必须新增操作日
志表。 5) 说明：
一般的表中应该包含上述字段，对临时或小型反复操作的表除外。 记录的删除，通过统一机制完成，比如“清除”等功能实现。
4.2.5 日期时间字段
尽量使用“DATETIME ”类型，在特殊情况下可以使用纯日期类型的字段，某些统计表中可以使用其
他类型表示时间的字段。
4.2.6 数字和文本字段
1) 数字和文本字段要充分考虑长度。在设计文档中必须明确的说明用户需求可能的最大允许范
围。
2) 数值型：除标志位字段（1位的数据），其他数值型字段设计为10位（为了扩展方便）。 3) 字符串：字符串默认设置长度为128位的VARCHAR2（保证字段足够长）, 标识性、标志性和类
型的字段根据实际情况确定长度，必须使用CHAR(X) 或NUMBER 。
4.3
键和索引
4.3.1 命名规则
1) 2) 3) 4) 5) 6)
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。
主键“PK_表名_主键名”；外键“FK_表名_外键名”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。 名称长度限制在30字节内。
4.3.2 键设计原则
1) 2) 3) 4) 5) 6) 7) 8) 9)
为关联字段创建外键。 所有的键都必须唯一。 避免使用复合键。
外键总是关联唯一的键字段。
使用系统生成的主键：尽量采用系统生成的键作为主键。
不要用用户的键：用户输入或可编辑的数据字段不要用于键，保障键值的正确性。 索引外键：表之间的关系通过外键相连接，这些字段应该增加索引。
不要索引注释字段：不要索引memo/note 字段，不要索引大型字段（有很多字符）。
不要索引常用的小型表：不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。
10）建立索引主要是出于增强数据访问性能的考虑。索引的种类很多，需要根据实际情况来建立适合的索引。对于可选择范围较小的字段，如地市等字段可以使用位图索引；对于聚簇表，可以使用聚簇索引；对于复杂条件的情况，可以考虑使用函数索引等。
4.4
视图设计原则（参考）
4.4.1 命名规则
1) 只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。
2) 3) 4) 5)
不允许使用小写字母。
格式“V_表1_表2…_表n ”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。
4.4.2 视图说明
视图的创建主要是为了简化查询，视图自己并不存储数据，而是在每次使用时查询数据，所以在效率上并不是很好。对于非常大的基表，如果仅仅是为了方便查询，不建议使用视图，但是可以考虑使用物化视图。
4.5 物化视图
4.5.1 命名规则
1) 2) 3) 4) 5)
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。
格式“MV_表1_表2…_表n ”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。
4.5.2 物化视图说明
1) 物化视图适用于大表用于查询的时候，可以根据查询条件把大表查分成多个物化视图，以简化
查询。
2) 物化视图有全量和增量刷新机制，可以根据应用系统的需要进行定制。
4.6
触发器
4.6.1 命名规则
1) 2) 3) 4) 5)
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。 格式“TRI_表_操作”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。
4.6.2 触发器说明
1) 触发器是一种特殊的存储过程，通过数据表的DML 操作而触发执行，其作用为确保数据的完
整性和一致性不被破坏而创建，实现数据的完整性约束。
2) 触发器的before 或after 事务属性的选择时候，对表操作的事务属性必须与应用程序保持一
致，以避免死锁发生，在大型导入表中，尽量避免使用触发器。
4.7
临时表设计原则
4.7.1 命名规则
1) 2) 3) 4) 5)
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。
格式“TMP_表1_表2…_表n ”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。
4.7.2 临时表说明
1) 对于复杂处理的中间结果可以用临时表来存储，尽量减少使用游标。 2) 临时表分类
3) On commit delete rows :事务级临时表 4) On commit preserve rows:会话级临时表
5) 区别：事务临时表，在提交事务后，表中的数据就消失了，但是会话临时表不会！~
会话临时表，提交事务后，依旧能查询，但是关闭数据后，重新连接时，表中的数据才会消失
4.8
有效组织数据库对象
4.8.1 存储过程分包存储
1) 对不同模块或相似功能划分的集合使用包来分类保存。
每个模块的存储过程和函数放在同一个包内。如果有全局公用的函数，则创建单独的公用函数包，大家可以资源共享，避免重复开发。 2) 脚本统一保存
所有人员创建数据库对象的脚本都集中到相关负责人处，并在VSS 或CVS 上按内容分开存放： 1). 创建数据类型脚本 2). 创建业务表脚本 3). 创建临时表脚本 4). 创建视图脚本 5). 创建主外键脚本 6). 创建索引脚本 7). 创建触发器脚本 8). 创建存储过程脚本 9). 初始化数据脚本 10). 创建作业脚本
4.9
包设计原则
4.9.1 命名规则
1) 2) 3) 4) 5) 6)
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。
格式“PKG_模块名(或功能类名) ”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。 名称长度限制在30字节内。
4.9.2 包说明
把同一个业务模块，或者相同功能的存储过程和函数，统一整理放入包内。 包内必须有完整的说明。
4.10
存储过程设计原则（参考）
4.10.1
1) 2) 3) 4) 5)
命名规则
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。 格式“P _动作_表名”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。
6) 名称长度限制在30字节内。 7) 过程内需要有异常处理。
4.11
函数设计原则（参考）
4.11.1
1) 2) 3) 4) 5) 6)
命名规则
只允许使用英文字母“A_Z”、数字“0-9”和符号“_”。 不允许使用小写字母。 格式“F_动作_表名”。
尽量使用英文单词或英文缩略语，各英文单词或缩略语中间使用符号“_”分割开。 不允许使用描述不明确的字母或数字。 名称长度限制在30字节内。
5.
5.1
数据完整性设计（参考）
完整性实现机制
1) 实体完整性：主键 2) 参照完整性：
父表中删除数据：级联删除；受限删除；置空值； 父表中插入数据：受限插入；递归插入；
父表中更新数据：级联更新；受限更新；置空值；
DBMS 对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制 3) 用户定义完整性：
NOT NULL；CHECK ；触发器；
5.2 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
5.3 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
5.4 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5.5 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
6.
数据库安全性设计
6.1 保证数据的完整性 6.2
保证数据可恢复性
1) 数据库应该有定期的备份（物理的、逻辑的）。 2) 生产库一定要开启归档。
3) 对于生产库，应该开启闪回来避免用户误操作导致的数据丢失。
a) 包括闪回数据库、闪回表、闪回数据。
6.3 其他安全原则
1) 采用数据加密
2) 数据访问权限采用最小授权的原则
对数据库用户应该有针对性的细粒度授权。具体到方案、表等。 3) 取消操作系统认证
4) 为SYSMAN/DBSNMP修改密码
5) 设置密码过期，并设置密码复杂度校验 6) 锁定不常用的默认用户 7) 为监听设置密码 8) 采用角色授权
9) 启用审计（一般情况不建议使用）
7.
7.1
数据库的物理实现
数据库的选择
7.1.1 数据库和版本的选择
到底要选择什么样的数据库，需要依据现实的条件和环境。主要应该考虑以下的因素： 1) 你要实现的目标（业务/功能要求，性能/可靠性/可扩展性/可用性要求）；
2) 当前数据库存储了多少数据，或者要构建的系统大概要多大的数据量，并需要考虑可扩展
性；
3) 应用程序要选择的操作系统和语言平台；考虑客户既有的数据库系统。 4) 预算有多少；
5) 是否有专业人员（DBA ）对数据库进行日常维护。
6) 如果选定了数据库， 对于具体版本，应该选择较新但是已经相对稳定的版本。
7.1.2 其他数据库和版本比较
针对oracle 来讲，到底是选择单实例，RAC ，还是HACMP 需要根据客户的具体需求来进行确定。 1) 一般要求的数据库，可以使用单实例；
2) 对于7*24的系统，而且不允许宕机（例如银行系统）则优先选择RAC 。 3) 对于某些7*24的系统，可以允许有几分钟的实例中断，则可以选择HACMP 4) 更高要求的系统则需要选择MAA
7.1.3 数据库版权
1) 不管是oracle ，SQL SERVER，还是DB2，对于商业用途都都要维护自己的版权，都是需要花钱
购买的，而且价格不菲。但是他们的功能和性能，都是经过考验的，售后的服务支持也做得很好。对于大系统的适用性也非常好。
2) 现在还有一些小型的数据库是免费的，但是一般对于较大的系统不适用。
3) MySQL 采用双重授权(Dual Licensed) ，他们是GPL 和MySQL AB 制定的商业许可协议。如果你
在一个遵循GPL 的自由（开源）项目中使 用MySQL ，那么你可以遵循GPL 协议使用MySQL 。否则，你需要购买MySQL
AB 制定的那个商业许可协议。这里最重要的一点就是要想免费使用MySQL ， 你所开发的软件必须是遵循GPL 的自由（开源）软件，虽然被批准的自由（开源）许可协议有很多个。
7.2
数据库运行环境
7.2.1 数据库硬件配置
数据库安装多需要的硬件配置需要根据选定的具体数据库的具体版本来决定。具体的要求需要查看相关文档。
例如在oracle10.2 for Linux x86的安装硬件要求如下：
1) 内存：至少 1024 MB物理内存 2)
3) /tmp目录至少 400 MB
4) Oracle 软件根据安装类型的不同设置在1.5 GB 到 3.5 GB 之间
5) 如果选择文件系统安装，需要1.2 GB的空间存放数据库预配置信息。
7.2.2 数据库运行操作系统和版本
数据库所选择的操作系统，很大程度上取决于用户的现有硬件环境。如果新搭的环境，还要看用户的预算。
1） 新环境，且用户期望较高，预算充足，建议选择IBM 小机，并安装AIX 操作系统。不论从对数
据库的支持，OS 的性能，还是易操作性，安全性方面都是首选。
2） 如果预算较窘迫，可以选择性能良好的PC ，选择Linux 操作系统。现在Linux 系统已经越来越
流行，而且对服务器配置要求不高；又可以配置RAC ，也方便之后的升级。
3） 不太建议使用windows 系统。但是Oracle 对windows 的支持还是比较好的，且在windows 上
的操作也很简单。如果有的用户对系统要求不高，那么可以选择windows 系统。
7.2.3 数据库运行操作系统的版权
1） 对于IBM ， HP，SUN 等的服务器的版权问题在购买时厂家都会很详细的说明。 2） 如果选择Linux 系统，则需要按规定购买。 3） Windows 也需要买正版。
4） 对于响应的oracle 软件，需要根据自己选定的服务器和操作系统选择特定的版本，oracle 公
司会提供后期的帮助。
7.3
数据库应用环境的物理结构（参考）
7.3.1 存储结构设计
1） 1) 存储的设计也需要和具体的环境相结合。到底是选择直连存储还是网络存储，都和用户的实
际需求密切相关。
2） 底层存储设备是否采用RAID ，采用那种RAID 方式也和用户对系统的要求，以及预算密切相
关。
a) 对于安全优先的用户可以采用RAID5，RAID1； b) 性能优先的用户可以采用RAID0,RAID10；
3） 如果是AIX ，HP 操作系统建议条件运行的情况下选择裸设备，以提高性能。 4） Linux 及Windows 操作系统无所谓裸设备。 5） 数据文件和备份文件分开存放。
7.3.2 数据存放位置
1） 不同的应用建议放在不同的表空间存储。 2） 有专门的索引表空间。 3） 有专门的临时表空间。
4） 数据文件进行分布在不同的磁盘存放，均衡磁盘I/O。 5） 对于某些大表建议单独创建表空间存放，并建立分区表。
6） 对于经常进行查询的大表，建议建立物化视图，提高查询性能。
7.3.3 存取方法设计
1） 尽量避免全表扫描。 2） 查询尽量使用索引。
3） 能在数据库端完成的操作在数据库端完成，减少交互。 4） JAVA 应用程序与oracle 的接口使用JDBC
.NET 应用程序与oracle 的接口使用ODBC
7.4
数据库性能和测试方法（参考）
7.4.1 数据库性能
数据的性能主要体现在处理能力和I/O两个方面。
1） 服务器的CPU ，I/O性能都是数据库性能的影响因素。 2） 大多数数据库性能瓶颈都是应用的不合理设计引起的。
3） 如果有大数据量的查询进行采用报表的方式，在系统空闲时间产出。 4） 导入、导出等操作尽量放在业务不繁忙的时间段来完成。 5） 数据处理尽量放在数据库端使用存储过程来完成。
6） 数据库的性能问题很多是处在SQL 的编写上，所以SQL 编写要严格遵循规范。7） 性能调优是一个循序渐进的过程。
7.4.2 测试方法
1） 数据库的性能测试可以采用常规的性能测试工具如LOADRUNNER 等来完成。 2） 上面的测试结果可以与ADDM 诊断工具相结合参照完成。
8.
8.1
数据库的管理
数据库管理员
系统数据库必须考虑数据库的管理问题。对于SQL SERVER数据库对DBA 的要求比较低，但是对于ORACLE,DB2等数据库，对DBA 的要求都非常高。要做好日常备份，监测，升级等工作；还需要进行应急恢复等紧急事务处理。DBA 的主要工作职责包括： a) 数据库安装
b) 数据库配置和管理 c) 权限设置和安全管理 d) 监控和性能调节 e) 备份和恢复 f) 解决一般的问题
8.2 数据库导入、导出
如果数据库选用oracle10g ，则尽量使用expdp/impdp进行导入导出。可以导出整个数据库，也可以分模式或具体到表进行导出。较低的版本使用exp/imp进行导入/导出。但是exp/imp的方式对大的系统，性能较差。
8.3 数据库备份、恢复
1) 每个系统为了保护自己的数据，及保证数据库正常运行，都需要制定适合自己的备份策略。并
可以写脚本在业务量较少的时间进行自动备份。对于备份应该有定期或不定期的测试。 2) 如果客户方有自己正在使用的数据库/系统备份工具，则使用工具。
3) 在没有第三方工具的情况下，使用RMAN 进行备份和恢复。对于具体的系统应该制定响应的备
份策略。一般来讲，应该是全备和增量备份相结合的方式。 4) 拷贝数据文件。
8.4 8.5
数据库记录清除 数据库维护 1) 2) 3) 4) 5) 6)
定期检查系统性能。
定期检查数据文件的使用情况，如果空间不够，需要增加存储设备。 定期对经常进行删除和更新操作的表进行索引的重建。 定期或不定期的进行表统计信息的收集，以提高效率。 定期对归档进行整理或清除，以释放空间。
对数据性能进行实时监测，发现问题及早解决。
9.
9.1
数据库的升级
数据库升级方式
数据库的升级参照oracle 文档进行。主要分为四种方式：
a) 导入导出。 b) DBUA
c) 手动升级 d) 数据复制
到底要采用哪一种升级方式，还需要根据具体的情况进行选择。1、2种都是非常简单的方式，但是在数据量大的情况下导入导出可能要消耗大量的时间。
附录
9.2
附录一 数据库设计文档说明
数据库设计文档除了本文档其他章节所述内容外，还应包含下列内容。
9.2.1 命名规则
表的命名规则：格式说明（按类型区分）。 字段的命名规则：格式说明。
9.2.2 数据库表创建文本
数据库设计完成后，应该根据相应的数据库，编写创建文本。
9.2.3 全部应用SQL 语句列表
为保障数据库设计的应用的完整性，在设计阶段即将项目需要的全部SQL 列出，从而检查数据库结构设计的完整性和使用的便利性，不至于在程序设计阶段发现数据库设计结构问题。
这里的SQL 语句是指完整的应用样例语句，不是程序中合成的语句，某些字段值就是具体的值，是直接可在数据库中运行的语句。
要求SQL 语句中关键字和表名使用大写，其它一律使用小写字母。
9.2.4 数据库设计文档必须有版本号
数据库设计文档必须包含相应的版本号。
9.3
附录二 数据库设计说明书评审表
编号YHXX-ZLJL-26 No. ：
Confidential
错误！未找到引用源。, 2000 Page 21 of 21