时间：2022-10-02 03:30:59
序论：速发表网结合其深厚的文秘经验，特别为您筛选了11篇数据库设计范文。如果您需要更多原创资料，欢迎随时与我们的客服老师联系，希望您能从中汲取灵感和知识！
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）31-0001-02
Optimal Design of Case Database in Database Course Teaching
HUANG Xin
（Jiaxing Technician College Department of Trade and Tourism，Jiaxing 314036， China）
Abstract：Aiming at the problem of selecting the teaching cases in， we analysis and research the case database designed int the domestic and mainstream textbook of database course. We propose a forum database named “simpleforumdb” as teaching and laboratorial case， and the detailed design of this database is given at the mean time.
Key words：database；course teaching；case database design
数据库技术是现代IT技术的重要支撑技术，是构建各类信息系统与应用系统的核心技术和重要基础[1]。教育部的相关文件指出“当代大学生应具备利用数据库技术对信息进行管理、加工和处理的意识与能力，用以解决本专业领域中的问题的能力”[2]。
国内主流数据库课程教材在组织内容时，虽然有的侧重数据库实现原理的介绍，有的以某一数据库管理系统（如Oracle、MySQL等）为平台介绍数据库技术的应用，有的兼顾理论和技术，但无一例外都引入了一个或多个数据库教学项目作为贯穿全书各章节、演示数据库关键概念和技术的案例。许多在教学中广泛使用的案例数据库较为简单，与实际工程项目相差较大，不能很好地覆盖数据库课程所有知识点，导致学生在未来工作中遇到实际项目时无法快速上手。如何设计合理的教学案例数据库已成为数据库课程教学亟待解决的重要课题。
1 主流数据库课程教材使用的案例数据库分析
下面从本专科两个教学层次，选取两本主流数据库课程教材中引入的案例数据库加以分析各自的优点和不足。
1.1 图书管理系统数据库
由南京师范大学郑阿奇教授主编的数据库课程系列教材被列为普通高等学校国家级规划教材，在职业院校和应用型本科院校的数据库课程教学中广泛使用。该教材以图书管理系统数据库作为教学案例[3]。
1.1.1 图书管理系统数据库逻辑结构
图书管理系统数据库的逻辑结构[3]如下：
1）管理员表：Administrator（角色名，密码，备注）
2）读者表：TReader（借书证号，密码，姓名，性别，出生时间，专业，借书量，照片，备注，联系方式）
3）图书表：TBook（ISBN，书名，作译者，出版社，出版年月，价格，复本量，库存量，分类号，内容提要，封面照片）
4）借阅表：TLend（借书证号，ISBN，图书ID，借书时间，应还时间）
5）还书表：HLend（编号，借书证号，ISBN，图书ID，借书时间，还书时间）
6）借出表：TBLend（图书ID，ISBN，是否借出）
1.1.2 图书管理系统数据库设计分析
优点：图书管理系统数据库设计较为完整，学习者不难结合其他程序设计语言（如C#、JSP、等）构造出一个实用的数据库应用系统作为课程设计。另外，该案例数据库的属性较为丰富，可涵盖SQL语言的主要数据类型。
不足：第一，可能是为了方便数据查询，图书管理系统数据库设计上存在不规范问题：部分表没有达到3NF的规范化要求。例如在借阅表TLend中，存在非主属性ISBN对码（借书证号， 图书ID ， 借书时间）的部分函数依赖[4]。还书表HLend也存在类似问题。改进的方法是从借阅表TLend和还书表HLend中去除属性ISBN，同时在TLend中加入“编号”属性作为该表的主码。第二，图书管理系统数据库的设计存在冗余问题，部分属性属于冗余属性，可以从相关表中去除[4]。例如图书表TBook中每本书的“复本量”和“库存量”可通过对借出表TBLend中相关记录进行聚集函数查询（使用函数count）得到，所以这两个属性应该从图书表Tbook中去除（如果存在，为了维护数据完整性系统将付出很大的性能代价）。第三，和企业实际工程项目相比，图书管理系统数据库略显简单。
1.2 学生选课数据库
由中国人民大学王珊和萨师煊两位教授编著的《数据库系统概论》一书引入的案例数据库――学生选课数据库在国内多数本科院校授课时广泛采用[5]。《数据库系统概论》也是国内第一部介绍数据库的教材，一直被国内大多数本科院校作为课程教材和主要教学参考书。
3、逻辑结构设计：将概念结构转换为某个DBMS所支持的数据模型；
4、数据库物理设计：为逻辑数据模型选取一个最适合应用环境的物理结构；
数据库系统是随着计算机在数据处理方面的应用发展而产生的。从19世纪50年代末开始,数据管理技术就一直是计算机应用领域中的一项重要技术和研究课题。利用计算机实现数据的管理经历了三个发展阶段:(1)人工管理阶段;(2)文件系统阶段;(3)数据库阶段。数据库系统的起源则在60年代中期,其发展始终以数据模型的发展为主线。按着数据库模型的进展情况,数据库系统的发展可以划分为三代:(1)第一代数据库系统,即层次数据库系统和网状数据库系统;(2)第二代数据库系统,即关系数据库系统(RDBMS);(3)第三代数据库系统,即面向对象数据库系统。一般来说一个完整的数据库系统由四个部分组成:数据库、数据库管理系统、数据库管理员和应用程序。目前关系型数据库的使用范围最广，人数也最多，不过针对某些特殊需求一般的关系型数据库则无能为力，比如医学数据库。医学数据库主要包括两种，一是医学文献的数据库，它包括了基础医学、临床医学、预防医学、药学、口腔医学、中医学及中药学等生物医学的各个领域的文献这种数据主要是提供有自由词，中文文题，英文文题，作者，摘要，参考文献，期刊名，出版年期，文献类型，特征词等的检索，这类医学数据库和一般的数据库系统没有太大区别；二是医学临床信息数据库，这种数据库用于记录病人全面详细的信息，主要用来支持医生的诊断，使得医生可以对医疗全过程（FullMedicalProcesses）进行规范、监督、控制、管理和分析统计。这种数据库数据结构较为复杂，通过传统的数据库形式已经无法满足要求。
2、国外的医学数据库研究现状
外国的医学数据库研究起步较早，已经取得了相当多的成果，像美国国家医学图书馆(NationalLibraryofMedicine)的可视化人体项目，他们通过获取男性和女性的1mm间隔的CT和MRI数据，用于医学教育和科研；美国的EMBBS医学图像数据库也主要用于教学和管理信息，该数据库拥有大量实用的临床照片、X光照片、文章、工作指南以及临床信息等;南佛罗里达大学的图像数据库，该数据库用于为研究机构提供图像，促进图像显示技术及教学辅助工具的开发;类似的还有Rorida的病理学者Dr.JohnMinarclk首先开创的肿瘤图像数据库(Tumorboard)，美国卡耐基梅隆大学的图像数据库等。
3、医学临床信息数据库的需求与设计
3.1医学临床信息数据库的需求和工程数据库特点
数据是数据库的核心，医学临床信息需要处理的数据具有一些特点：（1）类型比较复杂，既有传统的数值和文字，还有大量的临床照片、X光照片等信息，以后还可能进一步的有视频和音频信息需要存贮，类型多，所需的存储空间大；（2）临床数据需要进行动态的版本管理，应该能够体现出整个的诊断过程；（3）临床数据之间往往具有丰富的关联语义。这些特点和工程数据库有很多相似之处，这使得在进行医学临床信息数据库建立的过程中可以参考借鉴工程数据库的理论和知识。工程数据库是面向对象的数据库系统，能够支持复杂对象(如图形数据和工程设计文档)的表示和处理;可扩展的数据类型;支持复杂多样的工程数据的存储和集成管理;变长结构数据实体的处理;工程长事务和嵌套事务的并发控制和恢复;设计过程中多个不同数据版本的存储和管理;支持模式的动态修改与扩展和支持多种工程应用程序等。以上的工程数据库功能的实现方式都可以用来指导临床信息数据库的建立。
3.2医学临床信息数据库的设计
中图分类号：TP311.1 文献标识码：A 文章编号：1007-9416（2015）11-0000-00
Web服务中大多是以文件传输的形式来进行管理和运营的，但是随着社会发展信息量的加大，系统的反应速度受到很大影响，并且Web的应用领域逐渐扩大，已经不能够满足人们对于信息实时性的要求；另外，数据库近几年的发展十分迅猛且数据库的功能强大，能够快速检索查询大批量的数据，达到高效运行的目标。所以Web数据库就将Web技术与数据库技术相结合，这不仅能够将二者的优势相互结合，最重要的是可以将数据库的重要资源放到网络平台进行检索和浏览，使用户能够在浏览器轻松跨平台实现多媒体的服务。Web数据库作为研究设计的方向，与传统的数据库有明显的不同，比如体系结构以及访问方式等等。
1 Web数据库系统的体系结构
数据库系统的体系结构是涵盖了系统硬件、软件以及语言和算法的综合性概念，具体指的就是组成计算机系统的各部分之间的相互关系。对Web数据库系统结构的研究主要就是对其硬件分布及软件功能分配方面的内容。一个逻辑性清晰、开发容易和便于维护的数据库系统的建立必然是以一个统一的体系结构为指导，同时还要对系统的软件功能分配及硬件分布进行科学的规划。
数据库系统体系结构是随着计算机模式的改变而不断的改变，与计算机体系结构有着紧密的联系。伴着计算体系的集中模式和C/S模式以及三层C/S模式的演变，数据库体系结构也历经了集中式的主机结构和C/S结构以及多层的C/S结构演变。
2 Web数据库应用编程模型
Web数据库经过两种技术的结合，需要解决的就是各个模块之间复杂的信息传输交换方式以及对于数据库的管理和运行，另外还有在设计应用编程中模块和层次间的衔接和整合中存在的问题。
2.1 MVC模型
不管是什么样的应用程序都需要对相关的流程进行控制，根据这些就能够总结出常用的设计模型，在MVC模型中应用程序由三部分组成：模型：是程序的核心逻辑，面对应用领域的抽象对象，对其传输的信息要求进行检索和浏览，实现完成业务的目的。视图：这部分主要是面向用户的应用程序，负责用户与数据库应用程序的链接作用。一方面，视图能够为用户提供所需要的信息输入方式，并能够将需求以最快的速度传输给逻辑应用领域；另一方面，在传出形式上，将逻辑结果以一定的方式呈现给用户。控制：就是将逻辑程序与视图之间进行模式切换，方便两者的信息数据接收和传出。一方面，能够将视图传来的信息进行解读，以一种系统能够接受理解的方式传送出去；另一方面，将逻辑结果和模型的转变的执行进行处理，反馈给用户。
针对MVC模型应用程序的优化设计，包括对用户界面、流程控制以及逻辑方面的设计，将各部分进行分离，然后设计开发出个部分之间的接口，根据不同部分的主要功能，选择最合适的接口技术进行开发设计，最终形成完美结合，突出模型的技术细节和重要功能。
2.2 Web数据库应用系统设计开发中存在的问题
Web数据库的设计开发主要包括三个方面，分别是网页的设计、业务逻辑的设计以及数据库的管理设计。这些实际都是由多个开发人员应用不同的技术来结合成一个完整的程序的，所以编程技术很多，对应的客户的主机也要进行不断地升级才能够接受高功能的程序逻辑。在开发Web数据库的应用程序时，要考虑到运行速度、效率以及逻辑功能等多方面问题，同时各种技术自身都存在一定的不足，如果只采用一种技术来连接Web数据库各部分之间的接口会带来很大的运行困难，所以需要采用多种技术共同设计开发，保证Web数据库的高效率运行。
目前的Web数据库存在的种种问题，主要是编程模型的开发问题，从而造成的网页、逻辑和数据库之间的交流不顺畅。在设计开发的过程中引用系统、合理有效的编辑模型，要求设计和开发人员务必按照一定程序来对各部分接口进行独立的设计和开发维护，并保证不影响整体之间的交流和链接。
3 Web数据库的安全性设计分析
在对Web数据库进行设计的过程中首先需要对其工作环境进行最优化的系统安全配置，进而有效避免非法人员对Web站点的攻击，其具体包括了对操作系统、相关服务器的安全配置，只有将相关工作有效的结合起来，才能为Web数据库的建立提供一个安全的工作环境。3.1服务器的安全配置
对系统不同层次的运行环境要提供出具有较强针对性的安全机制。（1）操作系统的安全设置及措施。在用户进行使用系统之前首先需要做的就是登录，对于一些不能成功登录的用户，系统禁止其使用服务器的一切资源；对系统所有的默认账号和密码进行删除，同时限制用户尝试登录系统的次数；将系统磁盘设置为只读模式；对于系统中一些重要的目录要进行及时的备份，避免丢失；对用户的硬盘使用空间进行限制；对于允许访问系统的用户，对该用户资源访问权限进行设置。（2）数据库的安全设置。Oracle的安全模式设置为标准的安全模式，设置用户只能通过登录ID号以及相关口令进行数据库服务器的访问；对不同的用户在数据库的管理系统中给予不用的用户名设置；同时赋予不同的用户不同的权限；对系统中的用户名和对应口令进行定时的更改；定期的对应用程序中的用户进行审计。
3.2数据库应用程序的安全性设计及实现
对于服务端的应用程序采取了以下几种安全性措施，如下所述：（1）程序连接数据库的应用，Oracle中对数据库的连接用户进行用户名的设置，并赋予其相应的访问权限。同时在应用程序中设置了用户的登录名和登录口令。在应用程序进行数据库链接时，利用系统赋予的用户名和口令方能进行数据库的访问，随后实现Oracle原有的全部用户以及管理权限才能得以实现。具体实施方案：对于每一个数据库的应用程序设置一个相应的数据库账号，该账号对所有的数据信息都具备了操作的所有权限。另外，这对于系统的操作人员还需要创建一个系统账号。这样一来，当用户在访问数据库时，必然会以真正的数据库账号进行登录，然后是相关登录程序的执行过程。这一安全体系直接造成的结果就是整个应用系统成为了数据库的直接用户，而系统的所有操作人员却成为了数据库的间接用户。也就是应用系统在完成了相应的逻辑基础之上，还彻底的分割开了数据库和系统用户，为数据的安全提供了一道坚固的“防火墙”。（2）有效的增强用户的授权机制。在系统中不仅对Oracle的数据用户采用了授权机制，对系统账号也采用了手段机制，在上述的安全体系中，应用程序有效的为数据库和用户之间提供了一道安全防火墙，这对应用程序本身的要求就需要具备足够的安全特性。由于用户授权管理机制的严密性将对整个系统的安全将产生直接的影响，所以强化用户授权机制就显得尤为重要。本文研究的系统中将整个系统根据其功能特性将其划分为了多个最小的权限单元，这些单元同时都具备了可分配的特性，单元权限主要也就表现在了对数据库相应表格属性以及视图文件的操作等内容的划分上，然后再有效的结合相关系统操作人员的工作性质，运用工作组或角色的概念，完成了应用系统账号基本等级的创建工作，如根据等级的不同可将用户分为普通游客、初级会员、高级会员等，同时赋予了不同等级的用户群不同的使用权限，由此以来使得系统权限管理工作得到了有效的简化。为了使系统安全管理的灵活性有效提高，对系统某一等级的用户的权限，授权管理模块需要做进一步的限制工作，以实现所有权限均能达到任意组合的应用效果。除此之外，为了保证相关管理工作人员工作效率的有效提高，对所有的系统权限和每一种等级的用户群体以及不同用户所对应的不同组合权限，建立一部完善的数据词典，为的就是能够保证在任何一种工作环境下，工作人员都能够方便的对用户等级进行添加或者对不同等级的用户权限进行修改等操作；为了能够有效的限制某一系统应用账号的继续使用，该系统还需要设置相应的账号封锁或解冻的功能。（3）系统的审计和检测。系统的检测和审计工作对整个系统的安全稳定具有重要的意义。系统中的日志系统具有良好的数据库操作数据的采集以及记录功能。日志系统能够有效的记录某一用户在登录系统直到退出系统这一访问时间段内的所有操作，包括了用户在登录过程中的失败操作以及在成功登录系统后所执行的增、删、查、改等一系列的操作行为。日志记录的内容还包括了用户的IP地址以及名称、操作类型及操作对象等多项内容。为充分保证系统的安全性和稳定性，系统管理工作人员就需要对日志记录的文件内容进行必要的审计和检测工作，及时的找出系统中存在的不安全因素，并做出及时的处理。
4结语
近几年来，随着网络信息铺天盖地的传播，人们对信息的及时性和有效性的要求越来越高，Web技术的静态网页内容已经远远满足不了人们对于信息的追求。本文将数据库技术与Web技术完美设计结合，实现了全球信息资源的交流和共享，促进了各行业的迅猛发展。同时Web数据库的设计成功，也激励了企业单位的创新精神，建立自己的Web数据库系统以积极适应信息的快速发展。
参考文献
1.1虚拟数据库的基本操作数据库的基本操作分为插入，更新，删除，查询，针对每张表的操作方式，也是基于基本的四类操作，根据操作条件进行操作，总可以将数据转化成SQL语句进行操作。
1.2虚拟数据库的实现虚拟数据库操作的底层接口是各种物理数据库提供的API，虚拟数据库需要将这些API集中地封装起来，并根据用户的需求选择使用。封装结构可以如下所示。示例中仅封装了几个常用的数据库API，也可以根据需求追加定义其他API进入封装结构，也可以根据用户需求随时将其他数据库API封装进来。
2数据下发过程
2.1数据正常下发过程（1）底层网元首先向上层网元上报数据资源审计请求，并将底层网元的数据标识（通常为MD5校验码）带给上层网元。（2）计算底层网元数据审计标识，判断底层数据是否与上层网元数据一致，如果一致，发送数据审计结果正确给底层网元，否则发送数据不一致给底层网元。（3）根据结果判断，如果无需同步，向上层网元发送数据审计流程结束，如果需要同步，向上层网元发送数据请求，数据请求中包含请求数据表，以及数据指针，用于标识上次请求到的数据位置。（4）按照请求数据，从数据库中取出数据，以及数据指针，封装进数据下发包。（5）数据循环向下层网元发送，直到底层网元不在请求数据为止，同时底层网元上报数据审计流程结束，完成数据下发过程。
2.2数据异常下发过程（1）底层网元在无法打开本地的数据库情况下，判断为本地数据库已经损坏，向上层网元发送数据库崩溃通知。（2）生成下层网元的数据库，根据网元类型，通过FTP向底层网元发送数据库文件或者数据文件。（3）底层网元接收完成数据库后，打开数据库，上报数据资源审计请求。
中图分类号:TP311文献标识码:A 文章编号:1009-3044(2009)36-10176-02
Discussion on Principles for Database Primary Key Design
CHANG Yu-hui
(Jiangsu Technical Teachers College, Computer Engineering, Changzhou 203001, China)
Abstract: Primary keys are very important in databases, and .their design directly affects the application and performance of database systems. Starting from the concept of the primary key, the paper compares the commonly used design methods of the primary key, and proposes the relevant principles for primary key design.
Key words: Database; primary key
1 主键的概念及其设计主键的必要性
在我们进行数据库设计中,不可逃避的就是要定义数据库表的主键,主键的设计对整个数据库的设计影响很大,因此我们不得不要重视起来。那么我们首先来看看什么是数据库的主键和与它密切相关的外键。
1.1 主键
能够唯一表示数据表中的每个记录的字段或者字段的组合就称为主键(主码)。一旦确定为主键则该字段不可为空也不可以重复。一个主键是唯一识别一个表的每一记录,但这只是其作用的一部分。主键的主要作用是将记录和存放在其他表中的数据进行关联。在这一点上主键是不同表中各记录之间的简单指针。所以主键的值对用户而言是没有什么意义并且和它要赋予的值也没有什么特别的联系。比如学生表中的学号就可以定义成该表的主键。
1.2 外键
外键的定义是相对于主键而言的若有两个表A、B,key是A的主键而B中也有key字段则key就是表B的外键。比如另有一张成绩表表中也出现了学生表中的对应学号字段则相对于学生表学号就是成绩表的外键。
1.3 设计主键的必要性
有些朋友可能不提倡数据库表必须要主键,但在我的思考中,觉得每个表都应该具有主键,不管是单主键还是双主键,主键的存在就代表着表结构的完整性,表的记录必须得有唯一区分的字段,主键主要是用于其他表的外键关联,本记录的修改与删除,当我们没有主键时,这些操作会变的非常麻烦。主键除了上述作用外常常与外键构成参照完整性约束防止出现数据不一致。所以数据库在设计时主键起到了很重要的作用。
2 主键设计的原则
大家都设计过数据库,也为表定义过主键,我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都只是提了主键设计的方法而没有提及到主键设计的原则。针对于此,我对几种常用的设计主键的方法做了如下总结:
2.1 是否要采用自动递增的方式
对于以前谈到的主键,要求唯一性,因此大家都用自动递增的方式。这样的方式是非常不可取的。可能是为了方便插入记录时,不必去人为创建主键值。以为这样会方便,其实不是的。带来的麻烦要远远胜于这种所谓的"方便"。第一,数据导入不方便,经常会有从另一系统导入数据进来,自动递增的主键,将不允许原表中的ID被导入进来。这会导致主键丢失。第二,对于象订单这样的有主外键的表来说,如果订单的"主档表"主键是自动生成的,那么在保存一个订单时,会要求对主档表与明细表同进行事务保存,而此时,先要生成一条订单,然后取出这个订单自动生成的主键,然后再把此作为明细表的一个外键,进行明细的保存。这过程中,将变的复杂而且不可行,事务将如何处理呢?订单主档表插入记录后,要是明细保存时遇到错误,主档表记录还要进行删除。繁琐。插入成功以后,还要取出产生的最大值。这将是一个严重的浪费。记录多的话会影响速度,而且会存在并行插入。导致获取的记录可能是不正确的。因此在以上的严重问题下,请不要采用自动递增方式。
2.2 是否要采用int型作为主键
以前大家都采用int型作为主键,导致主键的值都是数字。其实我们也明白。并不是只是数字的东西就是数字型的,比如电话号码等。因此对于主键采用int型的优势是速度快插入查询时都可能会比其他的方式快。但我这种快的效果也未必有多明显比如以varchar(15)为例物理主键排序的数据会自动以主键进行物理数据排序。因此就算是字符型的数据在插入时也会插入到相应的物理位置上也就是说在插入时可能会影响一些速度。但在以后的查询中速度影响不会太明显。而我要说的不采用int型作为主键不是说里面不存数据。我还是建议大家在主键中存放数字这样的排序比较要比夹杂字母的排序来的快之所以要采用字符型也是为以后的数据导入作准备有一天会要求从其他表导入数据时可以在导入数据的主键上加一个特定字母来避免与原主键冲突。比如在导入数据的主键前加一个“N”字母。这也就不用担心要求导入数据表中的主键是数字型还是字符型了。
2.3 是否采用编号来定义主键
主键设计有个原则就是主键不应具有任何实际意义,这条其实是非常重要的。有人就是觉得编号本身是唯一的可以作为主键用但可能会为以后带来麻烦。因为带有实际意义的字段还是存在被修改的可能性,而对于主键最大的忌讳就是修改主键,这可能会导致非常严重的不可估计的后果。比如学生编号平时以为永远不会修改但修改的可能还是会存在。
还有一种表面上是唯一的但实际上应该是允许重复的。举个例子,订单编号应该是唯一吧。逻辑上是的,可是会存在这样的情况一张原来的订单是因为某个原因要求订单作废。那好给订单的状态标识为"cancel"。然后允许再次录入同样编号的订单。因此。对于这样的情况下在虽然有效的订单编号只有一个但在数据库角度会允许编号重复。所以不管如何还是建议大家为表都建一个没有任何意义的主键如ID。
2.4 是否要采用GUID作为主键
很多项目是多级建库的,经常需要数据导入、导出、合并很需要一套产生全局唯一主键的机制。一种方法是自己设计一套编码规范(类似于身份证、信用卡)最好有一个统一编码服务器;第二种方法也是自己产生主键为每一个独立的数据库分配一个NameSpace产生主键时前面加上这个NameSpace;最后一种方法就是UUID我想重点讨论一下后者。
UUID(Universally Unique Identifier)是通用惟一标识符,是128位比特的数字,用来惟一地标识因特网上的某些对象或者实体。UUID是是由开放软件基金会(OSF)作为分布式计算环境(DCE)的一部分而制定的标准。UUIDs的目的就是使分布式系统可以不需要重要的中央调合系统而能唯一地标识信息。这样,任何人能创造一个UUID和使用它来标识一些东西,而且,你有足够的信心来确定这个标识是永远不会被任何人无意地使用在任何东西上。因此,信息加上了UUID标签就能合并到单个数据库中而不用去解决命名冲突的问题。这个标准的广泛应用在微软的全球唯一标识符(GUIDs)上,GUID实现了这个标准。
用GUID作主键有它的优势与不足。优势是GUID具有唯一性,在任何情况下,可以产生全球唯一的值。这是GUID最大的优势,也方便数据导入,比如要求从另一个系统中把数据导入进来,那么不用担心导入时,会导致主键冲突。不足是GUID值太复杂、不易记忆,因为有时难免我们会用记录的方式来进行记录判断。而且数据太长,影响数据库效率。GUID的产生不是以一定的次序产生,对于按主键物理排序的数据库来说,如果在记录的前部插入一条记录,可能会导致后面N次方的数据条数后移。这将导致数据插入效率。而且这个值是随机、无顺序的。GUID的值有16个字节,与其它那些诸如4字节的整数相比要相对大一些。这意味着如果在数据库中使用unique identifier键,可能会带来两方面的消极影响,一是存储空间增大,二是索引时间较慢。因此GUID的采用应该要慎重。
3 结束语
数据库主键在数据库中具有重要的地位。主键的设计直接影响到数据库系统的应用和效能。数据库主键的设计并没有定论,因此,我们在设计主键时,因根据具体应用的需要,综合考虑各方面的因素,考虑数据库的规模,以及插入、删除、检索等操作的频繁来选择合适而快捷的数据库主键设计方法,从而达到优化数据库主键的目的。
参考文献:
[1] 张云涛.商业智能的设计部署与实现[M].北京:电子工业出版社,2004.
2 OFA结构的应用
OFA（最佳灵活体系结构）是Oracle数据库用于优化逻辑配置和性能提供的一种结构，通过OFA的利用能够简化Oracle数据库物理结构的设计，提高逻辑数据对象的分布效率。因此，首先需要根据数据库中的逻辑对象的使用方式以及物理结构对数据库的影响进行分类，这种分类包括将系统数据以及用户数据分开、一般数据和索引数据分开、低活动表与高活动表分开等。数据库逻辑设计的结果需要遵循几点原则：（1）将使用相同方式的字段类型进行统一存储；（2）按照标准使用对数据库系统进行设计；（3）存在用于例外的分离区域；（4）表空间冲突的最小化；（3）实现数据字典的分离。
3 SGA的应用
SGA（内存分配）是Oracle数据库中进行内存管理的关键模块。正确的SGA大小对提高数据库的性能具有重要作用。SGA主要包括四个部分。
（1）数据块缓冲区。数据块缓冲区是SGA中的一块高速缓存，大约占据了整个数据库的1%～2%左右，主要用于数据库中经常需要进行访问的数据块，因此，采用最近最少使用的方法对其空间进行管理。通过查询v$sysstat动态性能表，能够获取到数据块缓冲区的具体使用情况，当命中率低于85%时，则需要为其分配更多的内存。
（2）字典缓冲区。字典缓冲区中的信息主要包括用户账号数据、数据文件名、字段名、位置、表说明以及权限，该缓冲区也通过最近最少使用的方法进行空间管理。通过查询v$librarycache动态性能表，能够获取到字典缓冲区的具体使用情况，当命中率低于90%时，则可能需要增加共享池的空间来提高字典的缓存速度。
（3）重做日志缓冲区。重做日志缓冲区保存为数据库的恢复过程中用于前滚操作。
（4）SQL共享池。SQL共享池保存执行计划以及运行数据库的SQL语句的语法分析树，也采用最近最少使用的方法对其空间进行管理。如果设置过小，就可能导致语句连续不断地再装入库缓存，导致系统性能下降。
4 规范化与反规范
4.1 规范化
范式是符合某个级别的关系模式的集合，根据约束条件的差异，通常分为第一范式、第二范式和第三范式三种范式。规范化理论是以这些范式为中心建立的，规范化的基本思想是将数据依赖中不合理的部分逐步消除，从而使模式中的关系模型在一定程度上实现分离，因此，所谓的规范化从本质上来看就是概念的单一化。数据库的规范化管理，能够进一步减少数据冗余情况的发生，减少冗余数据对存储空间的占用，同时调用逻辑和物理I/O的次数也会减少，提高数据操作的效率。
4.2反规范化
数据库中数据的规范化并非一定能够实现数据库的最优性能，因为对数据库的查询通常需要更多的操作链接，从而对查询速度产生影响。因此，在数据库的设计过程中，有时需要对规范规则进行故意破坏，这样能够在特定的情况下改进数据库的查询性能，提高数据库的相应速度。
5 逻辑结构的优化
5.1 基本表的设计
5.1.1以用户为中心进行表的设计
当数据模型设计不合理时，则所有的SQL调整所发挥的作用都十分有限，规范化的表设计能够提高数据库的灵活性并降低整个系统开发和运行的开销。数据库的完整性检查能够在数据库中完成，同时也能够通过应用程序实现。如果将数据库完整性检查隐藏在应用程序中，则需要将大量的管理代码加入到应用程序中，同时还会导致服务器的信息通信量大大增加，这会在较大的程度上影响到整个系统的运行效率。相反，如果按照规范化理论对数据库的逻辑结构进行设计，则能够使数据库的完整性和一致性检查均在数据库服务器中实现，但是完全按照第三范式的要求进行数据表的设计会拆分大量的表，系统运行过程中，服务器需要频繁进行多表连接，影响整个数据库系统的性能。
因此，在对数据库表进行设计时，需要实现灵活性与核心事务性能之间的相对平衡，使数据库在尽量满足规范化要求的同时能够对其中的核心事务提供最直接的访问路径。比如，某个信息查询系统中存在销售表Distribution（Card、Operator）和营业厅表Office（Office、Operator）。在系统运行的过程中，如果有如下语句在检索条件中以较高的频率出现Where Distribution.operator=Office.operator，则可以考虑在销售表中增加一个字段Office。显然，如果一个operator只属于一个office，则在新生成的销售表中非主键office依赖另一非主键operator，这样就与规范化理论相违背，但是通过综合考虑，后者也是可行的。
5.1.2数据类型的合理使用
Oracle数据库提供了非常丰富的数据类型，通过准确的数据类型以及合理的数据长度对数据类型进行定义，不但能够有效减少数据冗余，同时还能够提高系统的检索效率。目前，常用的一些违背此原则的做法主要包括利用字符串存储日期数据、利用BLOB型存储文本等。要想避免这类做法，需要尽可能使用专门的数据类型对相应的数据进行存储，即日期型存储日期数据、数值型存储数值等。另外，在满足需求的情况下应该尽量减少占用空间。比如，数据能够采用Int型表示时，就不要使用Float型。在部分数据库中，如果无法确定数据长度，通常对其进行最大长度定义，这种方式通常会严重影响数据库系统的性能。
5.2 索引的优化设计
5.2.1管理组织索引
索引的建立能够实现对数据表中的逻辑值的安全映射，使其映射到安全的RowID。因此，通过建立索引的方式可以快速定位数据的物理地址。但是部分DBA发现，建立大型数据表的索引，往往会影响系统的性能，导致这种情况发生主要是由于SGA管理方式所引起的。Oracle数据库在管理数据块高速缓存时，索引数据往往能够获得更高的内存驻留权限，而在与普通数据竞争内存空间时，数据库往往会优先将普通数据移出内存空间。针对建立索引的大型数据库而言，在进行数据查询的过程中，索引数据可能会使用所有的数据块缓存空间，导致数据库频繁地从磁盘中进行数据的读取，影响系统性能。对此，在建立一个大型表进行分区之后，可以按照分区建立分区索引，如果大型表的索引数据查询频率过高，则可以不建立索引。另外，DBA在建立索引时，需要保证where语句中对建立的索引进行应用。由于索引必须指向适合的访问路径，因此在查询过程中如果简单的指定一个索引，则并不一定能够取得优化效果。
5.2.2聚簇
如果两个或者多个表需要进行查询连接，则可以考虑建立聚簇。比如，对通话信息表Dial（caller，receiver，time，length）和电话信息表Phone（name，address，number），如果下列检索语句在检索条件中经常出现Where receiver=‘123456’AND Dial.caller=Phone.number，则能够产生聚簇，在产生聚簇之后，两个表的物理存储结构会产生一定的变化，通话信息和电话信息的记录将会混合存储到一起，每个电话信息记录后面是该电话所拨打的所有电话记录。因此，如果能够确定Dial和Phone之间基于电话号码存在频发的连接，则可以采用一种聚簇文件结构提高两个表之间的连接效率。但是聚簇结构不利于两个表的单独查询，因此，在设计中需要对该逻辑结构谨慎使用。
5.2.3索引被使用的条件
优化设置的索引，必须充分利用才能够实现数据库访问速度的进一步提高。Oracle要使用一个索引，有一些最基本的条件：第一，Where子句中的这个字段，必须与索引的第1个字段相符合；第二，Where子句中的这个字段不应该参与到任何形式的计算中。
6 物理结构的优化
Oracle数据库物理存储结构的优化对于提高数据库的性能非常重要，物理结构的优化就是依靠提高磁盘读写的并行度、减少存储的动态扩展来实现数据库系统的性能优化。
6.1 磁盘读写的并行优化
磁盘I/O是数据库访问开销的重要指标之一，数据库物理结构的优化虽然无法减少从磁盘中读写数据的次数，但是可以通过并行化的方式，减少对此磁盘读写的竞争，从而提高系统的性能。提高磁盘读写并行化需要遵循两点基本原则：（1）将系统的SYSTEM、TEMP、ROLLBACK、REDO LOG表空间尽量放在不同物理磁盘中，能够有效减少系统进程与用户进程对I/O的竞争；（2）为表以及索引分别创建不同的表空间，并分别部署到不同的磁盘上，对于实现表和索引的并行访问十分有利。
6.2 减少存储的动态扩展
当数据库建立的时候如果没有分配足够的存储空间以及合理的增幅长度，则存储结构在运行阶段会形成动态扩展。在动态扩展过程中，需要通过SQL语句存取数据字典，以实现对空闲空间的利用，这个过程需要消耗较长的时间，还可能导致数据文件和表空间增加。这可能导致本来处于正常运行状态的系统的性能出现突然之间的大幅度下降。因此，在系统设计阶段，需要综合计算存储空间大小、增幅长度和最大值，并在此基础上对INITIAL、NEXT以及MINEXTENTS的值进行定义，实现数据库物理存储和动态增长次数的平衡。
7 结束语
Oracle数据库的库结构直接决定了数据库系统的性能，优良的库结构对于提高系统的性能具有重要作用，因此对整个库结构的优化也是数据库性能优化的基础，低劣的结构则可能导致整个优化无法发挥作用。良好的数据库系统不是靠调试产生的，而是需要优秀的设计，在Oracle数据库设计阶段就对整个系统的任务和需求进行充分的计算，不仅能够为应用程序的开发提供便利，同时还能使运行维护工作大大简化。
一、前言
数据库是承载数据的载体，存放和提供数据的“库房”，为我们进行数据查询、修改、管理等操作提供便利。建立数据库可以帮我们提升工作效率，通常适合较为庞大的系统数据存储。
例如，国网新疆电力目前覆盖全疆14个地州（市），涉及用户达2000多万人口，管理40多个部门和下属单位。这么复杂的机构需要高效稳定的IT系统支撑国网新疆电力公司。国网新疆电力目前有多个IT系统，比较重要的系统有综合管理数据库、营销系统数据库、ODS系统、财务系统。这么多系统数据日增长量超过2TB，这需要有效的优化手段解决数据库的性能问题。
目前通用的方式为采用Oracle数据库来对这些数据进行存储管理，面对厂里人员的变动则需要进行数据更新，随着系统长期运行、用户数和数据量不断增大以及业务不断变化，系统运行期间就会涉及到数据库优化。本文就从Oracle数据库优化进行简单的讨论，针对在优化过程中的一些注意事项、优化事项进行分析，为我们在工作中能够熟练的掌握优化技术。
二、Oracle数据库介绍
Oracle数据库，英文全名为Oracle Data-base，又被称为Oracle RDBMS或者直接简称为Oracle。目前最流行的B/S和C/S架构的系统中均应用到了数据库，由于它们的架构设计中都具有自己的服务器，而数据存在这些服务器中，则需要数据库对其进行储存。目前对于数据库的使用越来越广泛，随着人们对于数据库的研究越来越深入，逐渐出现了数据库云，将计算机的云计算应用到了数据库之中，这样使得多个数据库联合组成了更加庞大的数据库网，它们之间实现了数据共享，因此对于知识、信息的涵盖将会变得更广。云计算的实现，带给计算机网络发展巨大的空间，使得将世界的计算机联合起来形成一层一层的网络，与此同时也将数据库采用云管理，为数据库的发展提供更加广阔的空间[1]。
三、数据库优化方案介绍
多数研究者在面对Oracle数据库优化课题时，都会存在这样的思想误区，即认为只有在系统出现运行问题时才需要进行系统性能调整。而事实上，对Oracle数据库的性能进行调整和优化是一个漫长而复杂的过程，是贯穿于整个系统运行周期的。因此，在进行系统性能优化时，应按照以下流程来进行：对系统各功能组件和硬件设备进行正确的配置对数据库结构进行调整对SQL语句进行优化调整参数进行磁盘I/O与服务器网络性能的调整。以上流程是一个密切联系的整体，只有保证严格按照这一流程进行Oracle数据库系统性能调整，才能确保系统的性能达到最佳状态，真正实现Oracle数据库的优化设计。
图1所示是进行数据库优化时需要考虑的内容。优化是数据库体系的延续，数据库的结构和运行的机制决定了数据库的优化模式，所以说数据库的体系结构是优化的基石。如果对数据库的体系结构有深刻的理解，优化便水到渠成。反过来，通过优化数据库，可以更深入的了解数据库体系结构。数据库各个方面都有优化的余地，主要的优化方向分为实例的优化、数据库的优化、SQL语句的优化。其中SQL优化是重中之重。
对Oracle数据库进行优化，应该遵循优化SQL查询语句――索引优化――合理分布数据库物理文件――分析及优化Oracle内存分配原则。具体如下：
（一）SQL查询优化
SQL查询，主要针对数据库的信息进行搜索，寻找自己的需求信息。数据库内的一切操作都是经由SQL语句进行执行，因此SQL语句的执行效率很大程度上决定了Oracle数据库的性能。进行SQL语句的优化，首先应该构建原始数据库BASICPROJECT，其中包含了与生产数据库基本一致的数据库对象;其次，应该充分的利用SQL Trace、awrsqrpt、sqlplus中的autotrace、explain等跟踪技术对语句进行优化重写 [4]。我们在建立SQL语句的时候要尽量的避免出现相关子查询，以及选择语句的使用，这样就能从数据建立的时候减轻查询的负担。针对联合查询连接遇到5张或者5张表单以上的选择时，建议采用优化器对SQL语句中所包含的表单进行物理大小排序，建立起一定的查询顺序，来提升查询的效率。
（二）索引优化分析
索引技术是提升检索速度和系统性能的主要技术，对于数据查询来说，合理使用索引可以极大的提高查询的命中率和效率。索引是将表中数据的逻辑值映射到rowid中，所以在查询时使用索引功能能够快速的定位出查询数据的物理地址，从而找出数据。
索引对数据库的性能影响是巨大的，但索引不是万能的，数据库对索引的使用是有选择的，我们可以强制使用索引，也可以强制不使用索引。一般的情况下数据库会自动的判断是否使用索引，除非你明确的在SQL语句中指定。
所有索引的原形都是树状结构，由根、枝干和叶子组成。根和枝干中存放键值范围的导引指针，叶子中存放的是条目，条目中存放的是索引的键值和该数据行ROWID。索引的叶子间通过指针横向的联系在一起，前一个叶子指向下一片叶子，这样的目的是数据库在找到一个叶子后就可以查找相临近的叶子，而不必再次去查找根和枝干的数据块。
有的DBA发现了索引并不能提高查询速度，反而对整个数据库的性能有较大的不良影响，出现该问题主要是和SGA数据管理方式有关。当Oracle进行数据高速缓存管理时，普通数据的驻留权限要比索引数据的权限要低，当两者在空间上竞争时，索引数据往往会驻留;如果是大型表建立索引时，索引数据占了大部分的缓存空间，使Oracle只能通过磁盘读写来获得数据，所以在大型表分区后，伴随索引也得进行相应分区，索引的使用应该有一个指定的合适路径[5]。
（三）分布表空间
在整个数据库工作过程中，各相关进程会将数据库中的事务分别写到联机日志文件、归档日志文件和数据文件当中，这会不可避免的造成这三类文件之间的I/O冲突;并且归档日志文件因其特殊性，无法同系统、业务和索引这些表空间共存，这就需要一个独立的磁盘来完成合理分布表空间的功能，对各项数据进行合理的分配，以避免文件之间的I/O冲突。
（四）数据缓冲区的调整分析
数据库的缓冲区是SGA不可缺少的组成部分，它的作用是对磁盘的读入数据进行存储，存储的数据为用户共享。如果需要修改数据时，首先要从数据文件中将数据读取出来存储在数据缓冲区;如果用户对数据缓冲区的设置太小，那么数据的操作性能将会受到很大的影响。用户越多，该问题越突出，该问题的出现使得很多人去关心如何判断数据缓冲区大小，如何确定缓冲区的效率，该类问题可以通过计算命中率来进行确认。
数据缓冲区V$sysstat中的consistent_gets、db_block_gets是consistent mode和current mode模式下的数据读取总量，physical reads是整个磁盘物理数据读取总量，这两个数据的读取总量的比值就是所谓的命中率，如果两个数据比值<90%，那么就需要对该缓冲区大小进行调整[2]。
（五）共享池调整分析
共享池同样也是SGA的重要组成部分，它主要包含了数据字典高速缓存与库高速缓存，这两者的作用是对整个SQL程序进行语法分析、编译以及执行。
库高速缓存中会将解析过的SQL语句、PL/SQL（存储过程、函数、包）进行缓存。如果为了工作的需要，将解析过的SQL信息重用会提高整个数据库的性能，可以将解析过的SQL信息存储在共享池中，这就需要共享池的设置要足够的大。通过对V$librarycache查询实例来观察整个库高速度缓存的活动情况，其中的reloads和pins，它们分别是库高速缓存执行阶段的未命中数目和库高速缓存中被执行的次数，如果库缓冲区的失败率超过的1%，那么就需要对其进行调整。除此之外，还有些情况也需要共享池的设置要大，字典数据高速缓存的总丢失数和总的存取数的比值应该接近零，当这个数值超过10%，那么就需要对其进行调整。如将表定义的详细信息长期的存储在共享池中，将其进行重用，提高数据库的整体性能[3]。
通过V$rowcache来对数据字典高速缓存活动进行详细查询，其中的get misses和gets分别代表的是字典数据读取的失败和成功次数，通常要求的比值小于10%，若超过则需要进行及时的调整。
（六）日志缓冲区优化方案
日志缓冲区主要是保存了对数据库修改信息，设置的大小一般为2兆以内的内存，最小为500K。日志缓冲区也不能过小，否则会增加日志的写盘次数，从而为I/O接口增加负担。日志缓冲区中的常见指令为：immediate gets表示成功立即得到日志缓冲区次数;immediate misses 则表示未成功立即获取日志缓冲区次数。V$latch中的gets和misses表示成功获得缓冲日志次数以及未成功获得日志缓冲区次数，其失败率要小于1%，如果超出则需要对数据库进行调整。
（七）合理的使用工具
有时候想直接在SQLPLUS中看ASH/ADDM/AWR报告，用下面方法比较方便，因为AWR数据在数据库中默认只保留7天，当我们进行性能对比分析需要保留时段之前的AWR时，可以采用脚本定时将AWR报告输出保存。
ASH （Active Session History）
ASH以V$SESSION为基础，每秒采样一次，记录活动会话等待的事件。不活动的会话不会采样，采样工作由新引入的后台进程MMNL来完成。
生成ASH报告：
SQLPLUS>@？/rdbms/ashrpt.sql
ASH内存记录数据始终是有限的，为了保存历史数据，引入了自动负载信息库（Autom-atic Workload Repository ，AWR） 由后台进程MMON完成。ASH信息同样被采集写出到AWR负载库中。由于内存不是足够的，所以MMNL进程在ASH写满后会将信息写出到AWR负载库中。ASH全部写出是不可接受的，所以一般只写入收集的10%的数据量，而且使用direct-path insert完成，尽量减少日志的生成，从而最小化数据库性能影响。
写出到AWR负载库的ASH信息记录在AWR的基础表wrh$active_session_hist中，wrh$active_session_hist是一个分区表，Oracle会自动进行数据清理。
AWR（Automatic Workload Repository）自动工作负载信息库
AWR是Oracle 10g中的一个新特性，类似于10g以前的statspack。不过在使用上要比statspack简单，提供的性能指标要比statspack多很多，能更好的帮助DBA来发现数据库的性能瓶颈。
AWR 是Oracle安装好后自动启动的，不需要特别的设置。收集的统计信息存储在SYSAUX表空间SYS模式下，以WRM$_*和WRH$_*的格式命名， 默认会保留最近7天收集的统计信息。每个小时将收集到的信息写到数据库中，这一系列操作是由一个叫MMON的进程来完成的。
AWR存储的数据分类：
WRM$表存储AWR的元数据（awrinfo.sql脚本）
WRH$表存储采样快照的历史数据（awrrpt.sql脚本）
WRI$表存储同数据库建议功能相关的数据（ADDM相关数据）
生成AWR报告：
SQL>@？/rdbms/admin/awrrpt
根据向导来完成AWR报告的生成。需要注意的是，在选择时间范围的时候，中间不能有停机（如果显示的中间有空白行，表示有停机情况）。在选择报告类型的时候一般使用默认的HTML，方便查看。
查看数据库的AWR的设置：
SQL> select snap_interval， retention from dba_hist_wr_control;
SNAP_INTERVAL
RETENTION
--------------------------------- ----------------------------------
+00000 01：00：00.0（每小时收集一次） +00007 00：00：00.0（保留7天）
修改默认设置：
begin
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS（interval => 20，
retention => 2*24*60）;
end;
修改成每20分钟收集一次统计量，保留最近的2天统计量信息。
手动收集一次数据库的统计信息：
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
我们还可以通过DBMS_WORKLOAD_REPOSITORY包完成对基线、默认设置的修改等操作。
ADDM （Automatic Database Diagnostic Monitor AWR）
是Oracle内部的一个顾问系统，能够自动的完成最数据库的一些优化的建议，给出SQL 的优化、索引的创建、统计量的收集等建议。
ADDM报告生成：
SQLPLUS>@？/rdbms/addmrpt.sql
Oracle 性能调整最重要的就是对最影响性能的SQL的调整。在一个应用中，能够影响到数据库的只有SQL，也只能是SQL。我们不能一味依靠增强硬件，修改系统、数据库参数来提高数据库的性能，更多的应该关注那些最影响性能的SQL语句。ASH报告、AWR报告、ADDM报告都是能够找出最影响性能的SQL语句的工具。 在分析ASH报告、AWR报告的时候，最重要的就是关注SQL Statistics，SQL Statistics中最应该关注的是SQL ordered by Gets和SQL ordered by Reads两个指标。大量的Gets（逻辑读）会占用大量的CPU时间，大量的Reads（物理读）会引起IO的瓶颈出现。一般情况下，大量的Gets会伴随着大量的Reads出现。当然，我们可以通过增大SGA的大小来减少Reads的量。通过这两个指标找到了最影响性能的SQL，这是首要的，也是必要的。下一步就可以通过创建索引，调整SQL来提高SQL单独执行的性能，减少SQL执行时出现的高Gets，Reads。当然整体的性能影响还和excutions有关，如果这条SQL执行的次数过多，累加起来的量很大，那么就可以考虑通过在应用上缓存等手段来减少SQL执行的次数。另外还有一个需要注意的问题就是在开发过程中SQL一定要使用绑定变量，来减少硬解析（大量的硬解析也会消耗大量的CPU时间，占用大量的Latch）。在开发过程中有个原则就是：小事务操作完成及时提交。
我们使用这么多种方式、报告只有一个目的：找出最影响系统性能的SQL语句。找到SQL下一步就是对它进行调整了。
我们在监控数据库时，如果是当前正在发生的问题，我们可以通过v$session+v$sqlarea来找出性能最差的SQL语句。如果在一个小时以内发生的我们可以通过生成ASH报告来找出SQL。如果是1小时以上或几天我们可以通过AWR报告来找出几小时，几天以来最影响系统的SQL语句。ADDM报告基于AWR库，默认可以保存30天的ADDM报告。
我们也可以直接查询试图：
v$session （当前正在发生）
v$session_wait （当前正在发生）
v$session_wait_history
（会话最近的10次等待事件）
v$active_session_history
（内存中的ASH采集信息，理论为1小时）
wrh$_active_session_history （写入AWR库中的ASH信息，理论为1小时以上）
dba_hist_active_sess_history （根据wrh$_active_session_history生成的视图）
四、总结语
企业中使用Orcale数据库来储存数据，有效的改善了以前对于企业信息数据处理的问题。有效的节约了信息处理资源，且采用Orcale数据库将所有的员工等信息进行备份，方便以后查询，若数据库的数据不丢失，那么则能够通过查询进行查询。本文主要针对Oracle数据库进行介绍，然后根据数据库中的内容进行优化，为以后企业在数据库的优化上提供借鉴。
参考文献
[1]温创新.电视广告商务平台中Oracle数据库的ADICI设计与优化研究[D].中南大学，2011.
[2]王斌.基于Oracle数据库技术的航行情报系统（CNMS）性能优化[D].电子科技大学，2010.
[3]张舒.超大型Oracle数据库的基础设计和优化设计[J].价值工程，2011，10：178.
2元数据的定义和形成
元数据又叫做描述数据，是台湾学者通过英文翻译过来的（英文为Metadata），现在我国对该术语还没有形成统一的认识。国际标准化组织地理信息、地球空间信息技术委员会的地理信息元数据标准草案将元数据简单的定义为“数据的数据”。美国联邦地理数据委员会在数字地理空间元数据内容标准中将元数据定义为“关于数据的内容、质量、条件和其他性质的数据”。国际地球科学信息网络学会对元数据定义为“关于数据和信息资源的描述信息，他们描述、指向或者补充与之相关的信息内容”。元数据的定义和专业术语出现的时间虽然不长，但是元数据的本质内涵确实流传了很久。举一个简单的例子，在很早以前的图书管理当中，管理人员对书籍目录的编写，记载了书籍的各种相信内容，包括作者、写作时间、页数和字数等，这种对书籍信息的记录就可以理解为元数据。只不过在以前涉及到的数据不是特别复杂，只是到了现代随着网络技术的普及，数字资源呈现出爆炸性增长的速度，人们为了便于统计这些数字信息不得不将以前的文本化数据向网络表格化数据方面进行转变。从上世纪八十年代开始出现元数据的记录方式，到现在元数据的应用已经扩展到了各个行业。
3元数据标准内容分析
根据元数据的使用目的不同可以将元数据大体分为两类，即：管理和组织数据的元数据；浏览和导航数据的元数据。第一种类型的元数据的代表就是美国nasa描述遥感数据的目录交换格式标准（DIF），这一标准有一个典型的特征就是必备六个字段：登录目录标识、登录目录的名称、参数、原数据中心（包含名字、数据集标识、联系人等）和数据概要描述。另外，为了让信息表达的更加明确，这一标准当中还要增加字段，如传感器的名字、位置、数据分析、计划口令、品质等，增加这些字段可以提高用户的使用效率，尽可能的完善元数据。第二种元数据的代表就是澳大利亚新西兰土地信息委员会制定的元数据标准。这一标准确立的核心元素较少，能够让用户在最短的时间内查询到所需要的数据信息。核心元素能够说明现有数据的种类、数据信息、数据范围、与其他应用的作用，以及获取更多信息的位置等。核心元数据共分为九类三十二个元素：数据集中、展示、数据时间、数据状况、访问和浏览情况、数据品质、联系信息、元数据时间、元数据附加内容。除此之外，核心元数据还要制定了数据格式，使用指南，以方便用户查找信息。
4元数据表达方式的分析
美国联邦地理数据委员会的数字化地理空间元数据内容标准元数据信息单元是元素、实体（包括复合实体）和字集。元素是元数据的基本信息单位，元数据实体由元数据元素组成，元数据实体、元素则构成复合实体，最终部分元素、简单或者复合元数据实体组成元数据子集，元数据的组成结构从小到大排列为，元素、实体（复合实体）、子集。元数据是利用巴克斯诺尔范式进行表达的，巴克诺斯尔范式可以定义常规语言元素和属性标准语法，在确定复合实体和其他元素、实体间的联系的时候，采用类似于数学等式的关系将标识符和表达式用等号连接起来，以此来表表达式产生标识符这一进化关系。这一规则公式代表了各种符合的意义，从数学角度可以解释为，A=B+(C)表示A由B和可选项C构成，A=3{B}5表示A由B重复3到5次而成，子集、实体、元素之间的关系可以用元素比实体进一格的办法来表达，美国的数字化地理空间元数据内容标准利用这种方式可以清晰的表达数据实体和元素之间的各种关系，但是它也只是包含了标准化当中元数据和元素的定义，并没有规定数据的格式，有时候用元数据元素分层缩排来表示，有时候用编号系统表示，这就使得元数据使用起来并不简洁。为了解决这一问题，建立了空间数据信息交换网络，利用比较统一的SGML、Z39.50和其他协议来表示，可以更加灵活的执行元数据。ISO/TC211的元数据标准利用了图表和数据字典相融合的表达方式，清晰的表示了元数据内容之间的各种关系。数据字典可以详细的解释元数据的内涵，图表则是面向对象的统一建模语言UML静态结构图、ISO借口定义语言，在图表当中信息单位是包、类和属性。数据字典当中元数据的信息单元是子集、实体以及元素，这一标准说明了图表和字典当中的对应关系。因为静态结构图准确的解释了元数据的语义和句法结构规则，制定了标准的描述数据信息的方法和格式，通过辅助设计软件可以精确的表达数据元素关系，检查元数据设计的整体性和统一性，所以ISO/TC211的元数据表达方式对全世界各个行业的数据管理和服务产生了重要的影响。
5元数据网络管理模型分析
当下比较流行的元数据管理系统模式可以分为：集中式数据管理体系和分散式数据管理体系。集中式数据管理体系就是所有的元数据都聚集在一个元数据管理站点上，数据集元数据是通过数据制造者免费上传的，数据的使用者可以通过当下的数据管理站来进行访问好查询元数据。这一模式比较有代表性的就是英国地理数描述目录，这一机构的数据来源于国家制图机构。这种模式的优点就是使用者可以迅速的查找元数据，工作效率很高，当然缺点也很明显，就是这一模式分裂了这一管理系统和其他网络元数据体系的链接，导致这一体系的元数据数目较少，在数据信息的更新和维护方面就取决于元数据的上传者，元数据信息不能及时的更新，提供的数据有可能出现错误。分布式元数据管理体系就是要设立一个元数据网络交换的核心连接点，使用者可以在这一连接点进行元数据的查询，而对于元数据的供给者和元数据的数据制造者，则需要设立分节点，保存各种元数据的信息，然后将核心连接点和分节点联系起来。元数据的使用者不能直接访问数据的制造者，只能通过核心连接点来访问数据信息，进行元数据的查询。这一模式的代表性机构就是美国空间数据交换网络，它将用户、服务器内容、数据库服务器进行了分离。通过网关根据数据信息的类型、数据信息覆盖位置等条件构成元数据的查询界面，用户通过网络进行查询，核心连接点通过用户信息向分节点进行传输，然后在将内容反馈到用户浏览的页面当中。这种模式的优点在于能够增加元数据的数量，减少核心连接点对元数据的更新负担，缺点在于元数据的查询速度较慢，影响使用者的查询效率。
6元数据传输各式的统一
虽然当前已经制定了一些元数据的标准，但也只是确定了元数据的内容、含义、类别、组成结构等特征，但是这还不能满足元数据的使用要求，制订元数据标准的目的是为了元数据的查找和检索，了解数据信息和内容，因此必须要注重元数据的传输标准，以此为基础来设计元数据的管理体系，从而达到对元数据的搜寻、修改、更新维护和查询检索。在DOS环境下和ARC/INFO环境下，美国诞生了很多元数据录入和编辑的软件，澳大利亚也开发类似的软件，这些元数据软件都是为了便于自身的查询需求，符合各自制定的元数据标准的。但是各个元数据录入软件的数据格式却不相同，有的是文本格式，有的是HTML格式，还有的是关系型数据库格式，虽然方便了用户，但是在元数据的修改和维护方面成本很高，所以要制定统一的元数据转化标准，方便网络上的元数据交换。美国和澳大利亚建议更改统一的后缀格式，例如，将SGML/HTML的统一转换成XMLDTD或者是XMLSchema，将表格改编成ASCII的格式。这种方式优点在于有利于建设元数据索引和能够在不同地区的互联网当中进行元数据的查询。
7元数据管理平台设计和实现
7.1功能流程设计
功能流程设计需要满足元数据生命周期的要求，当前大多数公司单位都是分散式的数据管理体系，数据比较分散，需要采集多元数据并且简化数据的存储体系。可以将TSV（三层阶梯式图）引用到元数据管理体系当中，在元数据导入配置方面，可以利用悬挂点配置的方式，在任务采集的起始阶段可以配置相应的悬挂点（类似分支点），建设元数据的查询树，在数据源配置方面要表明数据源的类型、衔接数据、账户情况等，还要进行测试观察后续问题。为了更好的完善元数据的管理体系，保持元数据地图的完整性，需要对元数据进行完备的采集，采集方式又分为手动采集和自动采集。手动采集是对用户要求的数据库进行单次采集，自动采集则额外的配置采集时间和采集周期。
7.2元数据的浏览
将配置好的悬挂点体现在元数据的树状结构当中，以形象的结果提供给用户，基于TSV的思想元数据树需要具有三层以上的结构，首先是系统，其次是各系统数据库，再者是各数据库的下属表。在库级元数据方面需要展示各个表名和创立的时间，在表级元数据方面需要双击查看该表的详细信息，包括字段、约束、索引、键、视图等，在下拉菜单当中可以检索相应的元数据信息。在字段级元数据方面包括字段名、字段类型、字段解释、所属的表和库，前三项属于特点描述，后两项是定义描述，这样能够方便对字段进行分析和定位。
7.3元数据的构架设计
中图分类号：TP311.13 文献标识码：A 文章编号：1007-9416（2012）09-0186-02
在现在通信行业业务支撑系统建设中，由于数据库数据量的巨大，通常会根据不同业务模块建设成分布式数据库。如将计费帐务系统中数据可以按清单查询提供、前台帐务营收、计费处理、报表统计等划分，分布到不同的数据库实例，这样，通过模块化的数据分流，减轻了单一数据库的资源压力，均衡了负载，提高了各应用模块程序的效能。
同时，各数据库实例作为一个整体，存在一定的耦合性，分布的数据库之间的存在不同程度的相互沟通。如统计数据需要采集清单数据、营收帐务数据，计费处理时需要访问客户资料数据等。这些操作如果通过数据库之间进行操作就涉及到跨库操作的问题。
作为一个整体系统中的分布式数据库之间存在跨库操作是非常普遍的，尤其是数据库链接、同义词和存储过程的跨库操作在应用程序中广泛使用，这些给应用程序的设计实现带来了极大的方便，同时，从安全的角度也带来了一些问题。下面从安全管理的角度针对跨库操作进行一些讨论。
1、数据库链接（DATABASE LINK）
数据库链接是在分布式环境下，为了访问远程数据库而创建的数据通信链路。通过数据库链接隐藏了对远程数据库访问的复杂性。数据库之间通过数据库链接的创建，使得登陆到本地数据库上的用户可以访问远程数据库上的数据或进行其他跨库操作。可以说，跨库操作实现的基础就是数据库链接的使用。
创建数据库链接的语句如下：
CREATE DATABASE LINK 链接名 CONNECT TO 账户 IDENTIFIED BY 口令 USING 服务名；
数据库链接建立测试成功后，就可以采用以下形式来访问远程用户的表：
表名@数据库链接名
例如：在局域网上创建和使用数据库链接。
首先：在本地数据库网络服务名配置文件（tnsnames.ora）中添加远端数据库的服务名，假定服务名为remotedb。
然后：登录本地数据库，执行创建数据库链接命令：
CREATE DATABASE LINK link_rmt1 CONNECT TO scott IDENTIFIED BY tiger USING 'remotedb'；
测试是否可以使用：
SELECT sysdate FROM dual@link_rmt1；
如果正常返回远端数据库的系统时间，则数据库链接正常建立。
这里有两个问题需要注意，一是远端数据库scott帐户的权限，二是public参数。
建立数据库链接用到的远端数据库帐户的权限对跨库操作有很大的影响，从一定意义上说，跨库操作的安全级别就是由这个帐户所决定的。本地用户在本地数据库可以进行的操作，只要这个数据库链接用户拥有这些权限，本地用户同样可以用于远端数据库进行操作（通过数据库链接是不可以进行DDL操作的，如create、drop、truncate等）。本例中，如本地用户拥有resources权限，在本地数据库可以对自己的对象进行DML（update、delete、insert）操作。在数据库链接用户scott具有update any tables权限的情况下，本地用户是可以对远端数据库进行update any tables操作的，如
UPDATE scott2.test_table@link_rmt1 SET state=’YES’；
即在本地数据库只能对自己所属对象进行DML操作的权限限制，在远端数据库则没有这个限制了。
其次，在对public参数使用上，也是要比较注意的。Public参数在数据库中处于较低的级别，几乎不可能对登陆数据库用户进行限制访问。建立了public数据库链接，就等于承认在数据库链接的权限范围内，远端数据库对本地数据库所有用户都是开放的。
再者，在测试库等管理相对开放的数据库用权限较大的帐户建立了数据库链接，必将成为远端数据库管理的安全漏洞。
所以，在进行数据库设计时，应该严格控止public参数的数据库链接的建立；其次，建立的数据库链接尽量避免使用具有DML权限的用户；然后，对数据库中的密码定期进行修改也可起到一定修补安全漏洞的效果。
2、同义词（SYNONYM）
同义词是数据库方案对象的一个别名，经常用于简化对象访问和提高对象访问的安全性。在Oracle数据库中的大部分数据库对象，如表、视图、同义词、序列、存储过程、函数、JAVA类、包等，都可以根据实际情况为他们定义同义词。同义词可以分两类，分别是公用同义词与私有同义词。公用同义词由一个特殊的用户组Public所拥有，数据库中所有的用户都可以使用公用同义词。私有同义词是由创建他的用户或者方案所有。
使用同义词有以下优点，可以实现在不同的数据库用户之间的无缝交互，不同用户在访问时都使用同一个名称；可以创建指向远端数据库的对象，简化了远程数据库的对象的访问；可以为不存在的对象创建同义词，为应用开发提供了方便。
创建同义词语句：
CREATE OR REPLACE SYNONYM 同义词名 FOR 对象名；
跨库操作使用远程的数据库上的表的同义词，如下语句：
CREATE SYNONYM customer_t FOR erp.customer_t@remotedb；
在使用同义词时，Oracle数据库将它翻译成对应方案对象的名字。用户使用同义词访问对象可以分两部分，使用同义词和访问对象。例如，PUBLIC同义词是数据库中所有用户都可以使用的，但是要想实际访问到数据，还必须有访问原本对象的权限。如果没有同义词指向的表的操作权限，就会遇到报错信息“ora-00942： table or view does not exist”。
在跨库同义词的管理上，首先，要注意使用公用同义词，避免同义词和其他对象名称的重叠，如本地库中的表和指向远程数据库的表的同义词名称一样，可能就会在操作时造成一定混淆；其次，要注意同义词操作权限的赋予，尽量避免DML操作，当然，跨库同义词的操作权限是同数据库链接的权限相关的。
3、存储过程（PROCEDURES）
数据库中过程是一个PL/SQL块描述，它存储在数据字典中并可被应用调用。
存储过程在分布式数据库环境下，可以分两部分理解，
一个是跨库调用存储过程，二是在存储过程中使用了数据库链接或者跨库同义词。
跨库调用存储过程在实际应用中很少用到。当然，用不到更好。因为跨库存储过程的调用有很多限制，会发生意想不到的错误事件，如DDL操作在跨库操作时是不允许的；同时，由于执行跨库存储过程调用对本地用户和数据库链接用户的权限要求都比较高，也不利于数据库权限的管理。
在本地存储过程中使用到数据库链接或者跨库同义词在分布式数据库环境的应用中是经常用到的。好处是它可以增加数据库之间的耦合性，减少了设计难度，尤其是跨库同义词的使用，对程序的编写也提供了方便。缺点是，为了使用的方便而忽略了安全的考虑，如 public数据库链接、public同义词的使用，远端数据库DML权限的赋予等。因为这些设计是应用的基础，后期发现安全问题再去修复将花费相当的时间和代价。
4、结语
跨库操作方便了大型应用系统分布式数据库之间的互访性，同时，也带了安全隐患，只有从数据库管理的基础层面考虑，将设计基于安全层面之上，才能使应用得到充分的施展，也能将数据得到有效的保障。
参考文献
近年来，随着Web技术的蓬勃发展，人们已不满足于只在浏览器上获取静态的信息，想要通过它发表意见、查询数据。随着电子商务的普及人们开始参与一些网络商务活动，这就迫切需要实现Web与数据库的互连[1]。产品异地并行设计对数据的要求有一定的特殊性，主要有（1）产品数据多种多样。产品设计，特别是机械产品设计常常是大型而又复杂，在异地通过不同的设计小组，按不同的分工设计同一产品，所要管理和通讯的数据类型随着分工的不同而有不同的表现形式，如常规的数字组成的数据集，以图形、图象形式表达的产品模型数据，以文字形式描述设计的文档，还有图表、公式等形式，复杂多样。（2）产品数据交换频繁，流量大。产品设计是一个协同工作的创造性集体智慧凝聚的过程，要使设计顺利进行，分布在异地的不同设计小组之间就要经常性地进行数据交换，并且有些形式表达的产品数据是较大的文件。（3）产品数据的一致性要求高。分工合作的不同设计小组之间的设计任务是彼此关联，互相依赖的。如果其中一个数据改变了，相关联的数据必须跟着改变，在Web数据库设计时必须考虑数据的一致性问题。（4）产品数据的并发性访问频繁。由于异地产品设计的特殊属性，数据的并发性访问非常频繁。所以，进行基于Internet的产品异地并行设计的Web数据库设计与一般的电子商务不同，要充分考虑以上属性。本文结合我们近期开发的机械产品异地并行设计系统（RCDS， Remote Concurrent Design System），综合比较了多种当今流行的网络数据存取技术，设计出可靠安全的数据库系统。
1.1数据库连接方案选择
RDO、DAO和ADO是比较常见的Web数据库访问技术。
DAO (Data Access Objects) 数据访问对象是第一个面向对象的接口，它含有 Microsoft Jet 数据库引擎（由 Microsoft Access 所使用），并允许 Visual Basic 开发者通过 ODBC 象连接到其他数据库一样，直接访问到 Access 表。DAO 最适用于单系统应用程序或小范围本地分布使用，对大范围的异地并行设计显得功能不够强大。
RDO (Remote Data Objects) 远程数据对象是一个到 ODBC 的、面向对象的数据访问接口，它同易于使用的 DAO style组合在一起，提供了一个接口，形式上展示出所有 ODBC 的底层功能和灵活性。RDO 在访问 Jet 或 ISAM 数据库方面有一定的限制，而且它只能通过现存的 ODBC 驱动程序来访问关系数据库。但是，RDO 已被证明是许多 SQL Server、Oracle
以及其他大型关系数据库开发者经常选用的最佳接口。RDO 提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性，以及方法。对异地并行设计Web数据库来说也不是十分理想。
ADO（ActiveX Data Objects）为ActiveX组件中数据库访问组件，ASP就是通过它实现对数据库的访问。ADO 是 DAO、RDO 的后继产物。ADO 2.0在功能上与 RDO 更相似，而且一般来说，在这两种模型之间有一种相似的映射关系。ADO “扩展”了 DAO 和 RDO 所使用的对象模型，这意味着它包含较少的对象、更多的属性、方法（和参数），以及事件。例如，ADO 没有与 rdoEngine 和 rdoEnvironment 对象相等同的对象，可以包含 ODBC 驱动程序管理器和 hEnv 接口。尽管事实上接口可能是通过 ODBC OLE DB 服务提供程序实现的，但目前也不能从 ADO 中创建 ODBC 数据源。ADO 是为 Microsoft最新和最强大的数据访问范例 OLE DB 而设计的，是一个便于使用的应用程序层接口。OLE DB 为任何数据源提供了高性能的访问，这些数据源包括关系和非关系数据库、电子邮件和文件系统、文本和图形、自定义业务对象等等。ADO 在关键的 Internet 方案中使用最少的网络流量，并且在前端和数据源之间使用最少的层数，所有这些都是为了提供轻量、高性能的接口。同时 ADO 使用了与 DAO和 RDO相似的约定和特性，简化的语义使它更易于学习。
ADO最早是在IIS中引入的，主要用于ASP，用ADO可以使服务器端的脚本通过ODBC存取和操纵数据库服务器的数据。使用ADO的对象可以建立和管理数据库的连接，从数据库服务器请求和获取数据，执行更新、删除、添加数据、获取ODBC的错误信息等。ADO是ASP方案中最具吸引力的数据库连接控件，它为用户提供了连接任何兼容ODBC的数据库以及创建全功能数据库应用程序的能力。
ADO具有简单易用、高速、占用资源少等的优点。不同于DAO和RDO，ADO有着更高的执行效率。ADO 对象模型如图1a所示。每个 Connection、Command、Recordset 和 Field 对象都有 Properties 集合，如图1b所示。
a)
b)
图1 ADO对象模型及属性
应该说，ADO是微软的下一代数据库连接技术，用来全面取代RDO和DAO的数据访问工具。从发展趋势来看，ADO今后将逐步替代老的DAO特别是RDO数据访问接口，成为新的远程数据访问方法。所以，选择ADO作为产品异地并行设计的Web数据库接口技术是合适的。
1.2 ADO应用分析
ADO 并不是自动和现存的数据访问应用程序代码兼容的。当 ADO 封装 DAO 和 RDO 的功能性的时候，必须将许多语言要素转换为 ADO 语法。在某些情况下，这将意味着要对现存代码的某些功能做一个简单转换。在其他情况下，最佳的做法可能是用 ADO 的新功能重写该应用程序。
包含在 DAO 和 RDO 模型中的许多功能被合并为单个对象，这样就生成了一个简单得多的对象模型。然而，由于这个原因，起初可能会觉得找到合适的 ADO 对象、集合、属性、方法，或事件非常困难。与 DAO 和 RDO不同的是，尽管 ADO 对象是分层结构的，但在分层结构范围之外也是可以创建的。同时，也应当注意，ADO 当前并不支持 DAO 的所有功能。ADO 主要包括 RDO 风格的功能性，以便和 OLE DB 数据源交互，另外还包括远程和 DHTML 技术。
一般说来，在 ADO 的演化过程中，马上把大多数 DAO 应用程序（except possibly是那些使用 ODBCDirect 的应用程序）移植到 ADO 上为时太早，因为当前的 ADO 并不支持数据定义 (DDL)、用户、组等等。不过，如果只将 DAO 用于客户—服务器应用程序，并不依赖于 Jet 数据库引擎或不使用 DDL，那么就可能移植到 ADO。最终，Microsoft 将提供一个 ADO DDL 组件来帮助进行 DAO 到 ADO 的移植，并为 OLE DB 供应商提供一般的 DDL 支持。
在ASP中使用ADO技术来访问Web数据库，其应用前景是无可估量的。原理图如下：
图2 ADO在ASP程序中的应用
常见的数据库类型有面向对象的数据库（OODB）和关系型数据库。OODB对主流数据库应用开发来说是相当新颖的，使用OODB使应用程序中的数据对象与现实世界中的对象一一对应，面向对象数据库扩充了对象模型。一个常用的对象模型是由对象数据库管理组（ODMG）开发出来，具有比传统的关系数据库更优越的性能，但毕竟在目前还是一种探索阶段，暂时还未有相应的技术普及。
关系数据库已经是数据库体系的世界标准。当开发一个数据驱动应用程序时，大多数情况下用户需要访问网络（如Internet、Intranet等）上的数据信息，就RCDS就是建立在网络的信息通讯之上，是完全的客户机/服务器应用程序。
SQL Server是一个可缩放、高性能的关系型数据库管理系统（RDBMS），它的设计是为了满足分布式客户/服务器计算的需要，允许客户应用程序使用几个特定的工具和技术控制从服务器检索的数据。这些包括触发器、存储过程和规则的选项。因此，系统采用MS SQL Server7.0作为后台数据库。
数据模型通常有层次模型、网状模型、关系模型及OO（面向对象）模型等。其中关系模型是建立在数学概念基础之上的一种模型，由若干个关系框架组成的集合，它也是到目前为止最为成熟的一种数据库类型。本文RCDS采用MS SQL Server作为后台数据库，根据数据库工具和数据库特点，开发出一套可靠健壮的数据存储方案。
整个数据库共有AdminData、ChatNames、DesignUnits、Message、OnlineUnits、Products、RqtTasks、RqtTaskUnits、RqtDesignUnits、ShareData、Tasks、TaskUnits和UploadFiles等表格。在建立数据模型的时候首先考虑是要避免重复数据，也就是建立规范化数据库。规范化数据库可以通过被称为范式水平的指标来衡量，级别有第一范式、第二范式和第三范式，通常第三范式就是要达到的目标，因为它提供了数据冗余和开发简易性之间的最好折衷。
RCDS数据库正是按照第三范式标准来设计的，它保证了模型的精简和表格的紧凑性。而第三范式标准也最大发挥了关系数据库的优势，图3是部分表格的视图链接情况。
图3 关系表格视图 4.1 并发控制的处理 在多个用户同时访问一个数据库时就产生并发问题，特别是在其中一些用户对数据库有添加或删除修改等操作时，那么其他所获得的数据可能是一塌糊涂，甚至造成整个数据访问的冲突、终止，从而使系统发生混乱以至崩溃。RCDS采用的解决办法是锁定技术，总体上分为共享锁定和排它锁定两种类型（如图4）。前者是指同时有几个过程共享一个锁定，比如一个用户（或客户）正在读取一个数据，虽然在这之前他已经对该数据设置了锁（LOCK），但其他用户同样可以（也只能是）读取它。而排他锁定一般应用于对数据进行修改或更新（包括添加删除等）操作，即是用户在修改一个数据之前设置了锁定，在一定的时间里其他用户是不能访问到该数据的，只有等待锁定解除（UNLOCK）才能进行访问到它，当然在计算机处理的时候，其他的用户一般是感觉不到有这个等待时间的。通过这样的处理，就保证了数据的一致性。
a) 共享锁定
b) 排它锁定
图4 安全锁定类型
在ADO进行数据库操作时，它的锁定类型相对来说复杂一些。打开记录集时，可以指定锁定类型。锁定类型决定了当不止一个用户同时试图改变一个记录时，数据库应如何处理。ADO中的锁定主要有以下四种类型：
l AdLockReadOnly 指定你不能修改记录集中的记录
l AdLockPessimistic 指定在编辑一个记录时，立即锁定它
l AdLockOptimstic 指定只有调用记录集的Update方法时，才锁定记录
l AdLockBatchOptimstic 指定记录只能成批地更新
在缺省情况下，记录集使用只读锁定。要指定不同的锁定类型，可以在打开记录集时包含这些锁定常量之一。部分代码如下：
… …
Set MyConn=Sever.CreateObject(“ADODB.Connection”)
//定义数据库连接MyConn
Set RS=Sever.CreateObject(“ADODB.RecordSet”)
//定义返回数据记录集
MyConn.Open “ByktDB.dsn”//建立应用程序与数据源的连接
RS.Open “SELECT * FROM Mytable”， MyConn， adOpenDynamic， adLockPessimistic
//进行数据库操作，并且设置锁定
RS.Close
MyConn.Close
… …
数据的安全因素除了前面所提到的并行控制之外，还要考虑事务处理。网络数据库有其不同的地方，例如：假设某个时间有一个设计人员在你的站点上索取一些设计信息，有关的设计信息存储在两个表中。一个表用来保存该设计者的信息，另一个表包含了要索取的设计信息。该设计人员的信息已经输入了第一个表中。但是，就在这时，发生了意外情况，一道闪电击中了你的服务器，使第二个表没有被更新。在这种情况下，一个健壮的系统就必须保证最后的结果是两个表都没有被更新过。这时候事务处理就发挥了重要的功效。
使用事务处理，你可以防止第二个表没有被更新而第一个表被更新的情况出现：当一组语句构成一个事务处理时，如果一个语句没有执行成功，则所有的语句都不成功。不管是针对多个表，还是进行表内多个记录的操作，它们所需要的安全保证是一样的。事务处理的实现代码如下：
… …
Set MyConn=Sever.CreateObject(“ADODB.Connection”)
MyConn.Open “ByktDB.dsn”
MyConn.BeginTrans //事务处理开始
MyConn.Execute “INSERT DataTable(Num) Values(‘3628’)”
MyConn.Execute “INSERT Shipping (Address) VALUES(‘Paris，France’)”
MyConn.CommitTrans //事务处理结束
MyConn.Close
… …
在上面这段代码中，用BeginTrans方法和CommitTrans方法来标记事务处理的开始和结束。在BeginTrans方法被调用之后，CommitTRans方法被调用之前，不管出现什么错误，两个表都不会被更新，在这个过程中所有处理的数据都保持了完全可靠的一致性。
5 结论 ADO是由微软公司推出的以ActiveX技术为基础的数据存取方法。它的主要特点是使用更加容易，访问速度更快，支持建立各种客户/服务器模式与基于Web的应用程序。RCDS正是采用ADO 所基于的OLE DB技术，可以对电子邮件、文本文件、数据表格等各类数据通过统一的接口API接口进行存取，是远程数据存取的一个主要发展方向。
