软件数据库的面向对象视角_第1页
软件数据库的面向对象视角_第2页
软件数据库的面向对象视角_第3页
软件数据库的面向对象视角_第4页
软件数据库的面向对象视角_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、软件数据库的面向对象视角摘要随着越来越多在线数据的产生,并且通过计算机网络越来越容易获得,数据库也变得更加重要了。今天,众多领域的发展需求,例如,多媒体数据库,互动视频,流数据,数字图书馆等精彩视频节目,人类基因图和NASA的地球观测系统等科学项目,以及公司对巩固它们的决策支持处理和有用信息挖掘的渴望,正推动着数据库领域的发展。在商业上,数据库管理系统代表着最大和最具活力的市场之一。所以,有关数据库系统的研究回报丰厚!关键字:关系数据库系统,面向对象,概念模式,视图一从历史的角度回顾从数据库的早期开始,存储和操纵数据就一直是主要的应用焦点。第一个通用的DBMS是由Charles Bechman

2、于20世纪60年代早期在通用电器公司设计的,称为集成数据存储(Integrated Data Store).它奠定了网状数据模型的基础。网状数据模型由数据系统语言协会(CODASYL)标准化,并在整个20世纪60年代对数据库系统产生了巨大的影响。由于Bachman在数据库领域的贡献,他成为第一个ACM图灵奖(相当于计算机科学界的诺贝尔奖)的获得者,并于1973年接受了这一奖励。20世纪60年代末期,IBM成功开发了信息管理系统(IMS)DBMS。直至今天,它还在许多系统中使用。IMS奠定了另一个数据表达框架层次数据模型的基础。同时,美国航空公司和IBM联合开发出用于飞机订票的SABRE系统,它

3、允许多个用户通过计算机网络存取相同数据。有趣的是,今天SABRE系统被用于支持广为流行的基于Web的旅游服务,如Travelocity。1970年,Edgar Codd在IBM的San Jose研究实验室推出了一种新的,称为关系数据模型的数据表达框架。这后来被证明是数据库系统开发中的分水岭:它推进了几个基于关系模型的数据库管理系统的快速开发,并取得大量的理论成果,从而为数据库领域奠定了坚实的基础。Coff因为其杰出的工作而获得了1981年图灵奖。数据库系统作为学术学科已经成熟了,而且关系型DBMS的普及改变了商业应用前景。其益处被广泛认同,使用DBMS来管理公司数据变得很普遍。在20世纪80年

4、代,关系模型巩固了它作为主导DBMS模式的地位,而数据库系统继续被广泛使用。作为IBM的 System R项目的一部分而开发的关系数据库SQL查询语言,现在成为了标准查询语言。SQL于20世纪80年代末期得到标准化,目前的标准SQL:1999被美国国家标准协会(ANSI)和国际标准组织(ISO)接受。并发编程使用最广的形式就是数据库程序(称为事务)的并发执行。用户编写程序时不用考虑其他程序的运行,并发执行操作由DBMS管理。James Gray因他对DBMS事务处理领域的贡献而获得了1999图灵奖。也许,在DBMS的发展中,最重要的事是DBMS已经进入了因特网时代。第一代Web站点是把数据存储

5、在操作系统的文件中,而现在,使用DBMS存储数据并通过Web浏览器浏览数据已变得越来越普遍。通过Web可存取的表单界面来产生查询请求,并使用诸如HTML的标记语言将查询结果格式化,从而便于在浏览器中显示。所有数据库提供商都在增加它们的DBMS功能,使之更适于在因特网上部署。二物理数据库设计简介与数据库设计的其他方面一样,我们要根据数据的性质和用途来进行物理数据库设计。特别是,我们必须了解数据库所必须支持的典型的工作负载,工作负载是查询和更新的混合体。用户有一些特定的要求,如,某些查询或更新的执行速度应该有多快,或者每秒钟必须处理多少个事务等。在物理数据库设计过程中,工作负载的描述和用户的需求是

6、作出许多决策的基础。 为了获得一个好的物理数据库设计,我们还要调整系统的性能以满足用户的需求。设计者需要明白DBMS工作的细节,特别是DBMS所支持的索引和查询处理技术。如果数据库允许多个用户并发访问,或者是分布式数据库,那么这是设计任务就变得更复杂了,还需要考虑DBMS的其他特点。三数据库负载一个好的数据库设计的关键是对所希望的负载有准确的描述。一个工作负载的描述包括以下几个部分:1.一个查询及其出现的频率的列表,一个查询的频率指该查询在所有的查询和更新中所占的比例。2.更新及其出现的频率列表。3.每一种查询和更新类型所对应的性能目标。对于在工作负载中的每个查询,我们必须确定:需要访问哪些关

7、系。需要保留那些属性(在SELECT子句中)。在那些属性上有选择或连接条件(在WHERE子句中),以及这些条件具有多大的选择性。类似地,对工作负载中每个更新,我们必须确定:在哪些属性上有选择或连接条件(在WHERE语句中),以及有多大的选择性。更新的类型(INSERT,DELETE,UPDATE)以及所要更新的关系。对于UPDATE命令,要更新哪些字段。典型的查询和更新都带有参数,例如,借款或存款操作都涉及某个特定的帐号。这些参数的值决定了选择和连接条件的选择性。更新中包括一个查询部分,用来找到目标元组。这个部分可以得益于一个好的物理设计和索引。另一方面,更新操作一般还要做一些额外的工作,以维

8、护所修改的属性上的索引。这样,尽管查询总可以从索引受益,但是索引也可能使一个给定的更新加快或变慢。在生成索引时,设计者应该在头脑中进行一下权衡。四数据库调整的必要性准确地讲,在系统设计的初始阶段,我们很难得到工作负载的详细信息。所以在系统设计完以后,对数据库的调整就变得很重要,我们必须按照实际的使用模式来对初始的设计进行求精,以便获得好的性能。对于如何区别数据库设计和数据库调整,人们有不同的看法。一种看法认为,一旦初始模式、索引和聚簇决策已经确定,那么设计过程也就结束了。接下去对概念模式或索引的任何改变,都被认为是对数据库进行调整的活动。另一种看法是,对于概念模式的进一步求精(和受这些改进影响

9、的物理设计决策)也应该是物理设计过程的一部分。如何区分设计和调整并不是很重要的(五)数据库调整简介当数据库初始设计完成后,数据库的实际使用提供了一些有用的详细信息,它们可以用来对初始设计进行进一步求精。先前对工作负载的很多假设都可以用观察到的模式来代替;一般来讲,一些初始的关于工作负载的说明将得到验证,其中有一些可能是错误的。关于数据大小的初始猜测可以用实际的数据库的统计数字来代替(尽管这个信息会随着系统的不断进化而变化)。对于查询的仔细监测可龕发现一些预测不到的问题,例如,优化器可能不使用某些索引,尽管这些索引可以产生好的计划。 为了获得可能的最好的性能,对数据库进行连续的调整是很重要的。(

10、六)调整概念模式在数据库设计期间,我们也许会意识到,在给定工作负载和任何一组可行的物理设计选择的情况下,当前选择的关系模式并不能满足性能目标。如果是这样,我们也许必须重新设计概念模式(而且还要重新检查那些受到影响的物理设计决策)。在系统已经运行了一段时间后,我们也许会认识到在初始设计期间或之后重新设计的必要性。一旦数据库设计完成并且已经被装载数据了,如果要改变概念模式,就需要做出很大的努力去映射受到影响的关系的内容。然而,有时需要根据使用系统的经验来对概念模式进行修正。现在,我们从性能的角度来考虑概念模式(重新)设计中的一些问题。在对概念模式进行调整时我们必须考虑以下几点:我们也许应当采用3N

11、F设计来代替BCNF设计。如果将一个关系分解为3NF或BCNF有两种方式,那么应该根据工作负载来进行选择。有时我们需要对一个应景是BCNF的关系进一步分解。在某些情况下可能进行反规范化。也就是,可能将一组由一个大关系分解而得到的关系用它们的原大关系代替,尽管这样会引起一些冗余的问题。而且,我们可能在特定的关系上加上一些字段来加速一些重要的查询,即使这样会导致对一些信息的冗余存储(从而使得模式既不是3NF也不是BCNF)。关于规范化的讨论集中在分解技术上,实际上就是对关系的垂直划分。另一个技术是对关系进行水平划分,这将导致两个具有相同模式的关系。这里需要注意的是,这里讨论的不是一个关系元组的物理

12、划分;而是想创建两个不同的关系(可能具有不同的约束和索引)。另外,在重新设计概念模式时,特别是如果调整一个现存数据库的模式时,我们需要考虑是否定义视图来向用户隐藏这些改变,因为对于用户来说原始的模式可能更自然一些。(七)调整查询和视图如果一个查询比预计的要慢得多,那么我们就必须仔细检查并找出问题。通过对查询进行重写,并且进行一些索引的调整,常常能够解决问题。如果在视图上的一些查询运行得很慢,也可以进行类似的调整。当调整一个查询时,第一件事就是确定系统是否使用了你所希望的执行计划。由于一些原因,有时系统可能没有找到最好的执行计划。下面是很多优化器都不能有效处理的一些情况:含有空值的选择条件;选择

13、条件含有算数或字符串表达式,或者使用OR进行条件连接。例如,如果在WHERE语句中有一个条件E.age=2*D.age,那么优化器可能会正确利用现有的在E.age上的索引,但是不能正确利用在D.age上的索引。当将条件变为E.age/2=D.age时,将会出现相反的情况。不能识别出一个复杂的执行计划,例如不能发现在GROUP BY语句中含有的聚集操作的查询中的只读索引扫描计划。如果优化器不太聪明,不能发现最好的执行计划(使用DBMS支持的一些访问方法和执行策略),一些系统允许用户通过提供给优化器一些提示来指导计划的选择。例如,用户可能强迫系统使用特定的索引或连接的方法和顺序。如果一个用户希望以

14、这种方式来指导优化,那么他应该对优化和给定的DBMS的能力有一个全面的理解。(八)其他专题移动数据库便携计算机和无线通信的应用创建了一批移动数据库用户。一方面,这些用户只是简单地通过网络来访问数据库,类似于分布式DBMS。另一方面,不论是网络,还是数据和用户,都有一些新的特性,这就影响了DBMS中的许多构件,包括查询引擎,事务管理程序和虎伏管理程序。通过无线连接的用户带宽是以太网的1/10左右,是ATM网的1/100左右。因此通信开销比I/O和CPU开销更高。用户的位置通常是变动的,而且移动计算机的电池寿命是有限的。因此,除内容传输开销以及因位置的频繁变动而产生的开销外,真正的通信开销体现在连

15、接时间和电池的使用上。通常将数据生成多个副本,以使从不同位置的访问开销最小化。当一个用户移动的时候,一个事务可能需要从多个数据库服务器中访问数据,此时丢失连接的可能性比传统的网络要大。因此,集中式的事务管理也是不实际的,尤其是有些数据存储在移动计算机上更是这样。事实上,我们可能不得不放弃具有ACID特性的事务,而是为用户程序开发其他的一致性方法。主存数据库由于主存的价格已经很便宜了,许多应有可以购买足够的主存来保存整个数据库。而且,现代的CPU使用64位的寻址,有了很大的寻址空间。一些商用的数据库已有几个GB的主存。这促使重新考虑一些基本的DBMS设计决策,因为对于驻留内存的数据库,磁盘访问不再是主要的处理时间。主存也不能幸免于系统崩溃,所以仍然需要实现日志和恢复机制,以保证事务的原子性和持久性。在提交事务的时候,日志记录必须写到固定的存储中。这个处理可能会变成一个瓶颈。为了使该问题最小化,不是每完成一个事务就进行提交,而是收集已完成的事务,然后批

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论