毕业设计（论文）-SQL Server2005事务处理机制之研究.doc

XX大学 毕业设计SQL Server2005事务处理机制之研究学生姓名：XXX班 级：XXX指导老师：XXX系部：信息技术系提交时间：2010年5 月4日 SQL Server2005事务处理机制之研究目录1.前言12.事务处理机制22.1 事务的基础知识22.1.1 什么是事务22.2 事务的ACID属性22.2.1 什么是ACID属性22.2.2原子性32.2.3 一致性32.2.4 隔离性32.2.5 持久性43. 事务日记备份53.1处理方法53.2文件过大怎么处理与恢复54. 事务隔离级别84.1 隔离级别的概念84.2事务隔离级别104.2.1数据库事务处理中出现的数据不一致的情况105.锁实现机制125.1 封锁协议125.1.1一级封锁协议 (read uncommited)125.1.2二级封锁协议（read commited)125.1.3三级封锁协议（对应reapetable read）125.2浅析锁机制136. DBMS的责任和我们的任务147. 概念结构设计177.1 概念模型177.2 概念设计的主要步骤177.2.1数据抽象(data abstraction)187.2.2用ER方法进行数据库的概念设计188. 总结22221.前言 数据库事务是指作为单个逻辑工作单元执行的一系列操作。设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作：更新客户所购商品的库存信息 ；保存客户付款信息-可能包括与银行系统的交互生成订单并且保存到数据库中；更新用户相关信息，例如购物数量等等。正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态-库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。编者2010年5月4号2.事务处理机制2.1 事务的基础知识2.1.1 什么是事务事务处理是由以一个单一的逻辑单位完成的一系列操作，它可以由一系列的的SQL语句、SELECT、INSERT、UPDATE、DELETE组成，如果在该单位包含的操作执行完毕后没有发生错误，那么它对数据库所作的改变就是永久的了。如果一旦有错误发生，它就不会对数据库作任何修改或改变。要定义一个事务，需要使用BEGIN TRANSACTION命令，在这一命令之后的任何语句都将被认为是事务的一部分。命令COMMIT用来完成事务，并使事务对数据库所作的修改成为永久的。ROLLBACK命令用来取消一个事务，并还原事务对数据库所作的修改。下面是一个事务的例子：设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作：更新客户所购商品的库存信息保存客户付款信息可能包括与银行系统的交互。生成订单并且保存到数据库中。更新用户相关信息，例如购物数量等等。正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该客户银行账户存款不足等，都将导致交易失败。一量交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。2.2 事务的ACID属性2.2.1 什么是ACID属性事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使用应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。2.2.2原子性事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。2.2.3 一致性事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转账的应用程序时，应避免在转账过程中任意移动小数点。2.2.4 隔离性由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。2.2.5 持久性事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持SQL程序员要负责启动和结束事务，同时强制保持数据的逻辑一致性程序员必须定义数据修改的顺序，使数据相对于其组织的业务规则保持一致。程序员将这些修改语句包括到一个事务中，使SQL能够强制该事务的物理完整性。3. 事务日记备份3.1处理方法1. 清空日志DUMP TRANSACTION 库名 WITH NO_LOG 2. 截断事务日志：BACKUP LOG 库名 WITH NO_LOG3. 收缩数据库文件(如果不压缩,数据库的文件不会减小企业管理器-右键你要压缩的数据库-所有任务-收缩数据库-收缩文件-选择日志文件-在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了选择数据文件-在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了也可以用SQL语句来完成收缩数据库DBCC SHRINKDATABASE(库名)收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfilesDBCC SHRINKFILE(1)4. 为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)a.分离数据库: 企业管理器-服务器-数据库-右键-分离数据库b.在我的电脑中删除LOG文件c.附加数据库:企业管理器-服务器-数据库-右键-附加数据库此法将生成新的LOG，大小只有500多K5. 为了以后能自动收缩,做如下设置:企业管理器-服务器-右键数据库-属性-选项-选择自动收缩SQL语句设置方式:EXEC sp_dboption 库名, autoshrink, TRUE6. 如果想以后不让它日志增长得太大企业管理器-服务器-右键数据库-属性-事务日志将文件增长限制为xM(x是你允许的最大数据文件大小)3.2文件过大怎么处理与恢复一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大 1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server-SQL Server组-双击打开你的服务器-双击打开数据库目录-选择你的数据库名称（如论坛数据库Forum）-然后点击右键选择属性-选择选项-在故障还原的模式中选择“简单”，然后按确定保存 2、在当前数据库上点右键，看所有任务中的收缩数据库，一般里面的默认设置不用调整，直接点确定 3、收缩数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据方法在查询分析器，选中所要清理日志的数据库，执行如下SQL Backup log 数据库名 with no_log DBCC SHRINKFILE select fileid,groupid,name from sysfiles where groupid=0 以上结果，fileid为日志文件ID为test_lo你可以 Backup log test with no_log dbcc shrinkfile (2,2) or backup log test with no_log dbcc shrinkfile (test_log,2) 如果以后,不想要它变大,在数据库上点右键-属性-选项-故障恢复模型选择简单模型就可以了!SQL语句alterdatabase 数据库名 Set recovery simple SQL SERVER企业管理器-SQL SERVER组-服务器-数据库-选中数据库实体-右键-所有任务-分离数据库，然后到数据库所在物理路径下删除.ldf文件，再数据库右键-所有任务-附加数据库,即可，会重新生成日志文件。1.新建一个同名的数据库(数据文件与原来的要一致) 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库4.再重启sql server5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名) USE MASTER GO SP_CONFIGURE ALLOW UPDATES,1 RECONFIGURE WITH OVERRIDE GO UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME=置疑的数据库名 Go sp_dboption 置疑的数据库名, single user, true Go DBCC CHECKDB(置疑的数据库名) Go Update sysdatabases set status =28 where name=置疑的数据库名 Go sp_configure allow updates, 0 reconfigure with override Go sp_dboption 置疑的数据库名, single user, false Go6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.4. 事务隔离级别4.1 隔离级别的概念企业级的数据库每一秒钟都可能应付成千上万的并发访问，因而带来了并发控制的问题。由数据库理论可知，由于并发访问，在不可预料的时刻可能引发如下几个可以预料的问题：脏读：包含未提交数据的读取。例如，事务1更改了某行。事务2 在事务1 提交更改之前读取已更改的行。如果事务1 回滚更改，则事务2 便读取了逻辑上从未存在过的行。不可重复读取：当某个事务不止一次读取同一行，并且一个单独的事务在两次（或多次）读取之间修改该行时，因为在同一个事务内的多次读取之间修改了该行，所以每次读取都生成不同值，从而引发不一致问题。幻象：通过一个任务，在以前由另一个尚未提交其事务的任务读取的行的范围中插入新行或删除现有行。带有未提交事务的任务由于该范围中行数的更改而无法重复其原始读取。如你所想，这些情况发生的根本原因都是因为在并发访问的时候，没有一个机制避免交叉存取所造成的。而隔离级别的设置，正是为了避免这些情况的发生。事务准备接受不一致数据的级别称为隔离级别。隔离级别是一个事务必须与其它事务进行隔离的程度。较低的隔离级别可以增加并发，但代价是降低数据的正确性。相反，较高的隔离级别可以确保数据的正确性，但可能对并发产生负面影响。根据隔离级别的不同，DBMS为并行访问提供不同的互斥保证。在SQL Server数据库中，提供四种隔离级别：未提交读、提交读、可重复读、可串行读。这四种隔离级别可以不同程度地保证并发的数据完整性：隔离级别脏读不可重复读取幻象未提交读是是是提交读否是是可重复读否否是可串行读否否否可以看出，“可串行读”提供了最高级别的隔离，这时并发事务的执行结果将与串行执行的完全一致。如前所述，最高级别的隔离也就意味着最低程度的并发，因此，在此隔离级别下，数据库的服务效率事实上是比较低的。尽管可串行性对于事务确保数据库中的数据在所有时间内的正确性相当重要，然而许多事务并不总是要求完全的隔离。例如，多个作者工作于同一本书的不同章节。新章节可以在任意时候提交到项目中。但是，对于已经编辑过的章节，没有编辑人员的批准，作者不能对此章节进行任何更改。这样，尽管有未编辑的新章节，但编辑人员仍可以确保在任意时间该书籍项目的正确性。编辑人员可以查看以前编辑的章节以及最近提交的章节。这样，其它的几种隔离级别也有其存在的意义。在.net框架中，事务的隔离级别是由枚举System.Data.IsolationLevel所定义的：FlagsSerializablepublic enum IsolationLevel其成员及相应的含义如下成 员含 义Chaos无法改写隔离级别更高的事务中的挂起的更改。ReadCommitted在正在读取数据时保持共享锁，以避免脏读，但是在事务结束之前可以更改数据，从而导致不可重复的读取或幻像数据。ReadUncommitted可以进行脏读，意思是说，不发布共享锁，也不接受独占锁。 RepeatableRead在查询中使用的所有数据上放置锁，以防止其他用户更新这些数据。防止不可重复的读取，但是仍可以有幻像行。 Serializable在DataSet上放置范围锁，以防止在事务完成之前由其他用户更新行或向数据集中插入行。Unspecified正在使用与指定隔离级别不同的隔离级别，但是无法确定该级别。 显而意见，数据库的四个隔离级别在这里都有映射。默认的情况下，SQL Server使用ReadCommitted(提交读)隔离级别。关于隔离级别的最后一点就是如果你在事务执行的过程中改变了隔离级别，那么后面的命名都在最新的隔离级别下执行隔离级别的改变是立即生效的。有了这一点，你可以在你的事务中更灵活地使用隔离级别从而达到更高的效率和并发安全性。4.2事务隔离级别ACID，指数据库的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中，无法保证数据的正确性。4.2.1数据库事务处理中出现的数据不一致的情况在多个事务并发做数据库操作的时候，如果没有有效的避免机制，就会出现种种问题。大体上有四种问题，归结如下：1、丢失更新如果两个事务都要更新数据库一个字段X，x=100事务A 事务B读取X100 读取X100写入xX+100 写入xX+200事务结束x=200 事务结束x=300最后x=300这种情况事务A的更新就被覆盖掉了、丢失了。丢失更新说明事务进行数据库写操作的时候可能会出现的问题。2、脏读（未提交读）防止一个事务读到另一个事务还没有提交的记录。如：事务A 事务B读取X100 写入xX+100读取X200 事务回滚x=100读取X100 事务结束x=100事务读取了未提交的数据3、不可重复读一个事务在自己没有更新数据库数据的情况，同一个查询操作执行两次或多次的结果应该是一致的；如果不一致，就说明为不可重复读。还是用上面的例子事务A 事务B读取X100 读取X100读取X100 写入xX+100读取X200 事务结束x=200事务结束x=200这种情况事务A多次读取x的结果出现了不一致，即为不可重复读。4 、虚读（Phantom Read）事务A读的时候读出了15条记录，事务B在事务A执行的过程中删除（增加）了1条，事务A再读的时候就变成了14（16）条，这种情况就叫做幻影读。不可重复读说明了做数据库读操作的时候可能会出现的问题。5.锁实现机制x锁 排他锁 被加锁的对象只能被持有锁的事务读取和修改，其他事务无法在该对象上加其他锁，也不能读取和修改该对象s锁 共享锁 被加锁的对象可以被持锁事务读取，但是不能被修改，其他事务也可以在上面再加s锁。在运用X锁和S锁对数据对象加锁时，还需要约定一些规则，例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。5.1 封锁协议5.1.1一级封锁协议 (read uncommited)一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。一级封锁协议可以防止丢失修改，并保证事务T是可恢复的。使用一级封锁协议可以解决丢失修改问题。 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，它不能保证可重复读和不读“脏”数据。5.1.2二级封锁协议（read commited)二级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后方可释放S锁二级封锁协议除防止了丢失修改，还可以进一步防止读“脏”数据。但在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。5.1.3三级封锁协议（对应reapetable read）三级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。 三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。5.2浅析锁机制1共享锁 ServerSecurity/Database/SQL Server中，共享锁用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。默认情况下，数据被读取后，ServerSecurity/Database/SQL Server立即释放共享锁。例如，执行查询“SELECT*FROMAUTHORS”时，首先锁定第一页，读取之后，释放对第一页的锁定，然后锁定第二页。这样，就允许在读操作过程中，修改未被锁定的第一页。但是，事务隔离级别连接选项设置和SELECT语句中的锁定设置都可以改变ServerSecurity/Database/SQL Server的这种默认设置。例如，“SELECT * FROM AUTHORS HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。2更新锁 更新锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。因为使用共享锁时，修改数据的操作分为两步，首先获得一个共享锁，读取数据，然后将共享锁升级为排它锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个事务申请了共享锁，在修改数据的时候，这些事务都要将共享锁升级为排它锁。这时，这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请更新锁，在数据修改的时候再升级为排它锁，就可以避免死锁。3排它锁 排它锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。4结构锁 执行表的数据定义语言 (DDL) 操作（例如添加列或除去表）时使用架构修改 (Sch-M) 锁。当编译查询时，使用架构稳定性 (Sch-S) 锁。架构稳定性 (Sch-S)锁不阻塞任何事务锁，包括排它锁。因此在编译查询时，其它事务（包括在表上有排它锁的事务）都能继续运行。但不能在表上执行 DDL 操作。6. DBMS的责任和我们的任务企业级的数据库管理系统（DBMS）都有责任提供一种保证事务的物理完整性的机制。就常用的SQL Server2500系统而言，它具备锁定设备隔离事务、记录设备保证事务持久性等机制。因此，我们不必关心数据库事务的物理完整性，而应该关注在什么情况下使用数据库事务、事务对性能的影响，如何使用事务等等。本文将涉及到在.net框架下使用C#语言操纵数据库事务的各个方面。体验SQL语言的事务机制作为大型的企业级数据库，SQL Server2500对事务提供了很好的支持。我们可以使用SQL语句来定义、提交以及回滚一个事务。如下所示的SQL代码定义了一个事务，并且命名为MyTransaction（限于篇幅，本文并不讨论如何编写SQL语言程序，请读者自行参考相关书籍）：DECLARE TranName VARCHAR(20)SELECT TranName = MyTransaction BEGIN TRANSACTION TranNameGOUSE pubsGOUPDATE royschedSET royalty = royalty * 1.10WHERE title_id LIKE Pc%GOCOMMIT TRANSACTION MyTransactionGO这里用到了SQL Server2500自带的示例数据库pubs，提交事务后，将为所有畅销计算机书籍支付的版税增加 10%。打开SQL Server2500的查询分析器，选择pubs数据库，然后运行这段程序，结果显而易见。可是如何在C#程序中运行呢？我们记得在普通的SQL查询中，一般需要把查询语句赋值给SalCommand.CommandText属性，这里也就像普通的SQL查询语句一样，将这些语句赋给SqlCommand.CommandText属性即可。要注意的一点是，其中的GO语句标志着SQL批处理的结束，编写SQL脚本是需要的，但是在这里是不必要的。我们可以编写如下的程序来验证这个想法：DECLARE TranName VARCHAR(20)/TranSql.csusing System;using System.Data;using System.Data.SqlClient;namespace Aspcnpublic class DbTranSql file:/将事务放到SQL Server中执行public void DoTran()file:/建立连接并打开SqlConnection myConn=GetConn();myConn.Open();SqlCommand myComm=new SqlCommand();try myComm.Connection=myConn; myComm.CommandText=DECLARE TranName VARCHAR(20) ; myComm.CommandText+=SELECT TranName = MyTransaction ; myComm.CommandText+=BEGIN TRANSACTION TranName ; myComm.CommandText+=USE pubs ; myComm.CommandText+=UPDATE roysched SET royalty = royalty * 1.10 WHERE title_id LIKE Pc% ; myComm.CommandText+=COMMIT TRANSACTION MyTransaction ; myComm.ExecuteNonQuery();catch(Exception err) throw new ApplicationException(事务操作出错，系统信息：+err.Message);finally myConn.Close();file:/获取数据连接private SqlConnection GetConn() string strSql=Data Source=localhost;Integrated Security=SSPI;user id=sa;password=; SqlConnection myConn=new SqlConnection(strSql); return myConn;public class Test public static void Main() DbTranSql tranTest=new DbTranSql(); tranTest.DoTran(); Console.WriteLine(事务处理已经成功完成。); Console.ReadLine(); 注意到其中的SqlCommand对象myComm，它的CommandText属性仅仅是前面SQL代码字符串连接起来即可，当然，其中的GO语句已经全部去掉了。这个语句就像普通的查询一样，程序将SQL文本事实上提交给DBMS去处理了，然后接收返回的结果（如果有结果返回的话）。很自然，我们最后看到了输出事务处理已经成功完成，再用企业管理器查看pubs数据库的roysched表，所有title_id字段以PC开头的书籍的royalty字段的值都增加了0.1倍。这里，我们并没有使用ADO.net的事务处理机制，而是简单地将执行事务的SQL语句当作普通的查询来执行，因此，事实上该事务完全没有用到.net的相关特性。7. 概念结构设计概念设计的目标是产生反映企业组织信息需求的数据库概念结构,即概念模式。概念模式不依赖于计算机系统和具体的DBMS,设计的复杂程度大大降低,便于用户理解和交流。在这个阶段，设计人员仅从用户角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式（也称为“组织模式”）。然后再把概念模式转换成逻辑模式。7.1 概念模型表达概念设计结果的工具称为概念模型。对概念模型有以下要求：(1) 有丰富的语义表达能力,能表达用户的各种需求,包括描述现实世界中各种对象及其复杂的联系、用户对数据对象的处理要求的手段。(2) 易于交流和理解。概念模式是DBA、应用开发人员和用户之间的主要界。(3) 易于变动。概念模型能灵活地加以改变,反映用户需求和现实环境的变化。(4) 易于向各种数据模型转换。易于从概念模式导出与DBMS有关的逻模式。按照上述要求,传统的数据模型(网状、层次和关系模型）都不适合作概念模型，因为它们的语义表达手段都不充分。人们提出了许多概念设计的表达工具，其中最著名、最实用的一种是ER模型,它将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述。因此，概念结构设计阶段的主要输出是用ER模型表达工具表达出的数据库模念结构，即概念模式。7.2 概念设计的主要步骤概念设计的任务一般可分成三步完成，(1) 进行数据抽象,设计局部概念模式;(2)将局部概念模式综合成全局概念模式;(3) 评审。局部用户的信息需求是构造全局概念模式的基础，因此需要先从个别用户的需求出发，通常为每个用户或每个对数据的观点与使用方式相似的集团建立一个相应的局部概念结构。在建立局部概念结构时，常常要对需求分析的结果进行细化、补充或修改，例如有些数据要分为若干子项，有些数据的定义要重新核实等等。所有这些修改都要记入文档。设计概念结构时常用的数据抽象方法是“聚集”和“概括”。聚集将若干对象和它们之间的联系组合成一个新的对象，而概括则将一组具有某些共同特性的对象合并成更高一层意义上的对象。综合各局部概念结构就可得到反映所有用户需求的全局概念结构。在综合过程中主要处理各局部模式对各种对象定义的不一致问题，包括同名异义、异名同义和同一事物在不同模式中被抽象为不同类型的对象（例如有的作为实体，有的又作为属性）等问题。把各个局部结构合并还会产生冗余问题，或导致对信息需求的再调整与分析，以确定确切的含义。消除了所有冲突后，就可把全局结构提交评审。评审仍分用户评审与DBA及应用开发人员评审两部分。用户评审的重点放在确认全局概念模式是否准确完整地反映了用户的信息需求和现实世界事物的属性间的固有联系；DBA和应用人员评审则侧重于确认全局结构是否完整,各种成份划分是否合理,是否存在不一致性,以及各种文档是否齐全等。文档应包括局部概念结构描述，全局概念结构描述、修改后的数据清单和业务活动清单等。7.2.1数据抽象(data abstraction)数据抽象是对实际的人、物、事和概念的人为处理，它抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。抽象是人类认识和管理复杂系统的基础。抽象有两种形式，一种是系统状态的抽象（即抽象对象），另一种是系统转换的抽象（即抽象运算）。在数据库设计中，需要涉及到抽象对象和抽象概念。概念设计的目的就是要定义抽象对象的关系结构。一个数据库一般不是由独立的对象组成的，对象之间是有联系的，因此对象的形式就有两种方式：聚集和概括。“聚集”和“概括”在第二章中已经进过，这里不再獒述。7.2.2用ER方法进行数据库的概念设计用ER方法进行数据库的概念设计,可以分成三步进行:首先设计局部ER模式,然后把各局部ER模式综合成一个全局的ER模式,最后对全局ER模式进行优化,得到最终的ER模式,即概念模式。(1) 设计局部ER模式通常,各个用户对数据的观点可能不一样,信息处理需求也可能不同。在设计概念结构时，为了更好地模拟现实世界，可采取“分而治之”策略，即先分别考虑各个用户的信息需求，形成局部概念结构（即局部ER模式),然后再综合成全局结构。局部ER模式的设计过程(a) 确定局部结构范围。范围的划分有两种。一种是依据系统的用户集团组织进行自然划分，例如企业中可按职能划分成领导决策部门、销售部门、生产部门、财务部门等。另一种按用户要求数据库提供的服务归纳成几类，例如学校的教师数据库可以按提供的服务分为以下几类：教师的档案信息、业务信息、财务信息（工资、借款等），学术成果信息等等。这样做的目的是为了更准确地模仿现实世界，以减少统一考虑一个大系统所带来的复杂性。局部结构范围的确定要考虑下列诸因素：范围的划分要自然，易于管理；范围之间界面清晰，相互影响小；范围大小要适度，太小造成局部结构过多，设计繁琐，综合困难,太大则造成内部结构复杂,不便分析。(b) 实体定义。在每一个局部结构中从信息需求和局部范围定义出发，确定实体类型及其属性和键。实际上，实体、属性和联系之间并无形式上可以截然区分的界限，划分的依据通常有三条：一是采取人们习惯的划分；二是避免冗余，不要重复描述；三是依据用户的信息处理需求。在实体类型确定之后，它的属性也可随之确定。为一个实体类型命名并确定其键也是很重要的工作。命名应反映实体的语义性质，在一个局部结构中应是唯一的。键可以是单个属性，也可以是属性组合。(c) 联系定义。依据需求分析结果，考察局部结构中任意两个实体类型之间是否存在联系，若有联系，进一步确定是1:M,M:N或1:1等。还应考察一个实体类型内部是否存在联系，两个实体类型间是否存在多种联系，多个实体类型之间是否在存在联系等等。在确定联系类型时应防止出现冗余的联系（即可从其它联系导出的联系），以免将这些问题遗留给设计全局ER模式阶段。联系类型确定后，也需命名和确定键。命名应反映联系的语义性质，通常采用某个动词命名，例如“预订”、“选修”、“借书”等。联系类型的键通常是它涉及的各实体的键的并集或某个子集。(d) 属性分配。这一步的工作有两类：一是确定属性，二是把属性分配到有关实体和联系中去。确定属性的原则有三条：属性是不可分解的语义单位；实体与属性之间关系只能是1:M的;不同实体类型的属性之间应无直接关联关系。属性不可分解的要求是为了使模型结构简单化，不出现嵌套结构。当多个实体类型都用到同一属性时，将导致数据冗余，从而可能影响存储效率和完整性约束，因面需要确定把它分配给哪个实体类型。一般把属性分配给那些使用频率最高的实体类型，或分配给实际值少的实体类型。有些属性说明实体之间联系的特性，那么不宜归属于任一实体类型，而应作为联系类型的属性。例如某个学生选修某门课的成绩，既不能归为学生实体类型的属性，也不能归为课程实体类型的属性，应作为“选修”联系类型的属性。(2) 设计全局ER模式。这一步工作是把所有的局部ER模式综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式,而且必须合理地表示一个完整、一致的数据库概念结构。有些文献称此步工作为“视图集成”,这里“视图”特指本书所说的局部概念结构。全局ER模式设计过程如下：(a) 确定公共实体类型。这一步是确定各局部结构中的公共实体类型，为下一步合并局部ER模式打基础。当系统较大时，公共实体类型的确定并非一目了然。在这步中，仅根据实体类型名和键来认定公共实体类型。一般地同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。(b) 局部ER模式的合并。合并的顺序有时影响处理效率和结果。合并原则有三条：首先进行两两合并；先合并那些在现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。进行二元合并是为减少合并工作的复杂性。后两项原则是为使合并结果的规模尽可能小。(c) 消除冲突。由于各类应用不同，不同的应用通常又由不同的设计人员设计成局部ER模式,因此局部ER模式之间不可避免地会有很多不一致,称