https://www.bilibili.com/video/BV1st421p757/

演示视频：

4  系统功能实现

    在管理信息系统的生命周期中，仅过了需求分析、系统设计等阶段之后，便开始了系统实施阶段。在系统分析和设计阶段，系统开发工作主要是集中在逻辑、功能和技术设计上，系统实施阶段要继承此前面各个阶段的工作成果，将技术设计转化为物理实现，因此系统实施的成果是系统分析和设计阶段的结晶。

    在系统需求分析阶段，搞清楚了软件“做什么”的问题，形成了目标系统的逻辑模型。现在我们所要做的就是要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现系统的需求。

系统的概要设计中最重要的就是系统的模块化。模块化是指解决一个复杂问题时自项向下逐层把软件系统划分成若干个模块的过程。每个模块完成一个特定的功能，所有的模块按某种方法组织起来，成为一个整体，完成整个系统所要求的功能。在之前的系统分析中，通过对系统功能的分析，已经得出了初步的系统功能模块图，主要包括四大模块，在四大模块之下又进行了细分。

 将系统划分为多个模块是为了降低软件系统的复杂性，提高可读性、可维护性，但模块的划分不能是任意的，应尽量保持其独立性。也就是说，每个模块只完成系统要求的独立的子功能，并且与其他模块的联系最少且接口简单，即尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

    在系统的概要设计中采用结构化设计以需求分析阶段产生的数据流图为基础，按一定的步骤映射成软件结构。首先将整个系统化分为几个小问题，小模块。然后，进一步细分模块，添加细节。模块划分完，接下来只要通过添加细节，就可以逐步实现系统的功能。本次使用的主要是JSP方面的技术，对于页面的布局相对来说比较简单，只要再添加一些相关的主要代码在其中，然后编写一些辅助的Java代码就可以使这些页面连接起来，初步实现一些功能；其中主要的还是数据库代码的编写。

4.1系统登陆页

   （1）描述：为了保证系统的安全性，要先使用本系统必须先登陆到系统中。

   （2）程序运行效果图,如图4-1所示。

    这是系统的主登陆界面，管理员通过这个界面进入到要操作的内部界面，管理该系统的相关功能。

图4-1系统登陆页面设计

   （3）在登陆页面输入用户名和密码以，选择登陆身份后，点击提交按钮，跳转到登陆的service中，在该service中会对用户名，密码，验证码进行判断，并根据相应的用户角色进入对应的页面

4.2系统主页面

    (1) 描述：管理员主页面：左方页面展示了管理员可操作的七大功能，进入相关的管理页面可以链接到子菜单，并且高亮显示，每个管理模块下面都有相应的子菜单。主要有修改个人密码功能，教师信息添加功能，教师信息管理功能，教师信息统计功能，教师信息导出功能，工资添加和工资信息统计功能。

    (2) 程序运行效果图，如图4-2所示。

图4-2管理员主页面

在每个jsp页面将会对相关用户进行拦截操作，这样可以提高安全性，防止用户不经过登陆页面而进入任何子菜单页面：

4.3教师信息管理

4.3.1信息录入

   （1）描述：管理员输入教职工相关正确信息后点击录入按钮，如果是没有输入完整的信息，都会给出相应的错误提示，不能录入成功。输入数据都通过form表单中定义的方法οnsubmit="return checkForm()"来检查，checkForm()函数中是各种的校验输入数据的方式。主要是管理员根据实际的需要去添加老师的一些基本信息。

   （2）程序效果图，如图4-3所示。

图4-3教师信息录入

   （3）流程图，如图4-4所示。

图4-4教职工录入流程图

4.3.2信息编辑

   （1）描述：管理员点击左侧的菜单“教师管理”，页面跳转到做教师界面，调用后台的servlet类查询所有教师的信息。教师信息的编辑是实验的很关键的一部分，因为老师的信息是工资的主体。设置老师工资的这个标准当然是不固定的，主要是可以有一个基本的概述，然后再根据实际情况进行完善，达到所需要的目的。管理人员可以根据学校老师的加入而输入数据路系统中，然后，可以修改老师的基本信息，或者彻底删除某位老师的相关信息。

   （2）程序效果图，如图4-5所示。

图4-5教师管理界面

4.3.3信息统计

   （1）描述：管理员根据现实需要可以查询教师的信息并进行相应的编辑和管理，因为是模糊查询，所以，设置了两个关键字，一个是姓名，学校同名的老师不可避免，然后再用专业进行限制，可以方便快捷的查询到所求老师的信息。

   （2）程序效果图，如图4-6所示。

图4-6教师信息查询界面

4.3.4信息删除

   （1）描述：先是点击教师信息管理，页面跳转到教师管理界面，浏览所有的教师，点击要删除的教师，弹出确定对话框，即可删除该教师信息。

   （2）程序效果图，如图4-7所示。

图4-7教师删除界面

4.4工资信息管理

4.4.1工资录入

   （1）描述：在此页面主要是输入工资数、奖金等信息，然后选择教师，所有信息都不能够为空，是否为空也是通过form表单中的οnsubmit="return checkForm()来检查。工资信息管理是系统的核心，有了前面老师基本信息的搜集添加后，就是对某一月份的工资进行编辑，每位老师有自己的基本工资和奖金的数目，管理员根据相应的实际情况进行添加，方便管理。

   （2）程序效果图，如图4-8所示。

图4-8工资信息录入

4.4.2工资信息查询

   （1）描述：管理员点击左侧的菜单“工资管理”，页面跳转到工资管理界面，调用后台的gongziServlet类查询出所有的工资信息，并把这些信息封转到数据集合List中，绑定到request对象，然后页面跳转到相应的jsp，显示出来。这是管理员根据所属月份进行查询，随机的输入某年某月就会得到所有老师的基本工资和奖金数目。方便管理者的进一步工作。

   （2）程序效果图，如图4-9所示。

    其中还有教师工资导出这一块儿，作为本设计的一个亮点：

    将数据库中老师的信息结合后可以导出到excel中，方便进一步的统计打印，完整而且简洁，如图4-10所示。

图4-10教师工资导出

下面是WPS表格，如图4-11所示。

图4-11教师信息表格

4.5修改个人密码

   （1）描述：输入用户名和用户的原有密码，输入新密码以后点击修改按钮即可修改密码成功。

   （2）程序效果图，如图4-12所示。

图4-12修改密码

4.6安全退出系统

   （1）描述：点此按钮回到系统的主页面。

5  系统测试

5.1系统测试目的与意义

    系统测试是管理信息系统开发周期中一个十分重要而漫长的的阶段。其重要性体现在他是保证系统质量与可靠性的最后关口，是对整个系统开发过程包括系统分析、系统设计和系统实现的最终审查。

系统测试的任务是尽可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统“做得怎样”。这这阶段又可以分为三个步骤：模块测试，测试每个模块的程序是否正确；组装测试，测试模块之间的接口是否正确；确认测试，测试整个软件系统是否满足用户功能和性能的要求。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒测试，应覆盖系统随偶联合的部件，系统测试是正对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出需求规格不符合或与之矛盾的地方。

在设计系统的过程中，存在一些错误是必然的。对于语句的语法错误，在程序运行时自动提示，并请求立即纠正，因此，这类错误比较容易发现和纠正。但另一类错误是在程序执行时由于不正确的操作或对某些数据的计算公式的逻辑错误导致的错误结果。这类错误隐蔽性强，有时会出现，有时又不出现，因此，对这一类动态发生的错误的排查是耗时费力的。当面对这些问题时，要仔细专心的检查各个模块功能的逻辑以及相关代码，通过黑盒白盒等各种测试方法以及各种测试用例对系统进行测试，从而发现系统中的漏洞，找出相关的代码进行修改，以完成对程序的调试。

对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50％。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。

在实践中，软件测试的困难常常使人望而却步或敷衍了事，这是由于对测试仍然存在一些不正确的看法和错误的态度，这包括:

   （1）认为测试工作不如设计和编码那样容易取得进展难以给测试人员某种成就感；

   （2）以发现软件错误为目标的测试是非建设性的，甚至是破坏性的，测试中发现错误是对责任者工作的一种否定；

   （3）测试工作枯燥无味，不能引起人们的兴趣；

   （4）测试工作是艰苦而细致的工作；

   （5）对自己编写的程序盲目自信，在发现错误后，顾虑别人对自己的开发能力的看法。

    这些观点对软件测试工作是极为不利的，必须澄清认识、端正态度，才可能提高软件产品的质量。

5.2测试方法

    测试方法有很多，如模块测试、联合测试、验收测试、系统测试。

   （1）模块测试

    在这个测试步骤中所发现的往往是编码和详细设计的错误；

   （2）联合测试

    在整个系统作为一个整体进行调试。高层由上而下，低层由下而上，到中层进行会合；

   （3）系统测试

    在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误；

   （4）验收测试

    在这个测试步骤中发现的往往是系统需求说明书中的错误。

    与开发过程类似，测试过程也必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。大型软件系统通常由若干个子系统组成，每个子系统又由若干个模块组成。因此，大型软件系统的测试基本上由下述几部分组成：

    首先进行模块测试在模块测试中检测出该模块中所存在的编码和逻辑错误，进一步可以减轻随后的系统测试的负担，随后进行系统测试，在此次测试中发现软件设计方面的一些错误，这方面也可能涉及到软件功能方面的一些内容，通过对此次测试结果的分析以及分析之后对软件进行的调试，使得软件更符合客户的要求，最后进行验收测试，通过验收测试可以得到更深层次的客户要求，从而使得软件更加贴合用户的使用习惯以及要求。

    一个系统不可能没有错误，但是经过一次次的测试，减少了系统中各种漏洞的情况下，也使得软件开发者一步步的完成了使用者的要求；前两步不测是为了减少软件中的错误，最后的验收测试，就是为了使得所开发的软件更好的满足用户需求，也使得软件更符合用户的习惯；所以测试不是测试完一次就完成了，而是测试一次，修改一次，直到最后用户满意为止。

5.3测试的主要内容

为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试、确认测试和系统测试。

   （1）单元测试

    单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。

   （2）集成测试

    集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

   （3）确认测试

    确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试

后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。

   （4）系统测试

    软件开发完成以后，最终还要与系统中其他部分配套运行，进行系统测试。包括恢复测试、安全测试、强度测试和性能测试等。

单独对系统的测试主要从以下几方面入手：

    功能测试：测试是否满足开发要求，是否提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

    强度测试及性能测试：测试系统能力最高实际限度，即软件在一些超负荷情况下功能实现的情况。

    安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。针对本系统主要是对权限系统的测试和对无效数据、错数据、和非法数据干扰的能力的测试。

5.4测试过程

    在测试之初，由于将数据库中的数据是随便输入，没有实用性，为了使系统更加完善，在系统测试的过程中，本系统将一开始编程随便输入的数据全部清理后，输入了一些有效的测试数据，这样可以更真实的反映系统的功能实现情况。

    这样不断发现问题，经过反复的测试、调试，把问题一个个的解决，最终系统可以正常运行。

    测试流程：

   （1）打开系统首页，输入错误的登录信息登录；

   （2）输入正确的登录信息并登录；

   （3）测试结果。

如表5.1所示。 

5.5其他错误

    在程序设计实现的过程中不可避免的会产生各种难以预料的错误，如书写错误、传值类型不一致、参数传递问题等等。这些都需要通过细心的检测与不断的调试才能够排除。比如在servlet路径配置时因粗心错误导致运行导致所报错误，如图5-2所示。

图 5-2由于servlet路径配置错误,运行时的提示

结  论

    本次毕业设计将我大学四年所学的软件工程理论知识用到了具体的实践中去，深化了理论知识，同时也锻炼了动手实践能力。在这段日子里，我查阅了许多有关教师工资管理信息系统的资料，翻阅了许多JSP的书籍，结合自己的经验，详细调查了教师工资管理的工作内容与细节，开发设计了这个教师工资管理系统，虽然企业每个学期都会有相应课程的课程设计和实训来作为动手练习训练，不过在本次毕业设计具体的实践的时候还是遇到了很多小问题，比如说在jsp页面将输入框设为不可用是添加属性readonly=“true”，而我在实际编程中却错写成disable=“true”，这样直接导致了request对象取不到数据，调试了程序很久才发现request对象获得的返回值一直是空，之前一直以为是代码哪里出了问题，总是在查源程序的逻辑。这些虽然都是小问题，但是由于不细心在具体实践中却浪费了不少时间，看来平时还是要多多实践才是。

    在系统的开发过程中，我运用到了B/S三层结构技术和自己在平时学习中掌握的一些技术，通过这些技术的实现，整个系统的性能得到了大大的提高。这些技术都在论文中做了比较详细的介绍。本系统还存在许多的缺陷和不足之处，比如很多细节上做的还不行，有些功能模块还应再加强。希望在以后的时间里，我可以把这些缺陷都弥补过来，进一步完善系统。

    通过本次毕业设计我锻炼了自己的自学、研究能力，也从中学到不少在企业在课堂上学不到的东西。通过实践我也深刻的体会到软件开发的艰辛及问题解决后的喜悦心情，培养我的独立思考问题的能力，同时也增强了我的理论联系实际的能力，这为自己以后的工作奠定了良好的基础。

    本系统可以在很大程度上减轻教师工资管理人员的工作负担，但由于时间和技术条件的限制，还存在一些不足之处，有些功能还需要改进，还应该做进一步的系统调查需求分析工作，更深入的完善系统。总之，一个紧跟时代步伐的真正使用的软件必需有一个不断完善改进的过程。

参考文献

[1] 白秋产，高爱华，沈显来.基于VFP的做工师傅教职工管理信息系统[J].计算机与数字工程，2006，

   34（01）：143-145

[2] 舒攀，陈金刚.数字化校园建设中师资管理系统的实现与设计[J].武汉工程大学学报，2008,30

  （04）：108-111

[3] 艾灵仙. 高校系级网站构建平台的设计与实现[J]. 科技信息-2008年16期

[4] 张国玉，牟宗国.加强和完善教职工管理工作探讨[J].四川教育学院学报，2007，23（SI）：19-20

[5] 严勇杰.浅谈如何加强高职院校教职工管理工作[J].科技信息，2008，（29）：592-593

[6] 许义金，郑初华.教职工管理中心管理信息系统开发[J].南昌航空工业学院学报，2006,20（4）

    94-97

[7] Joshua Bloch.Effective Java[M].Piscataway,N.J:IEEE Press,2009

[8] Abdellatif T.and F.Boyer. A node allocation system for deploying JavaEE  Systems on

   Grids.Hammemet,Tunisia.2009

[9] J.M.Hellerstein,M.Stonebraker.Architecture of a Database System[J].Foundations and Trends in

   Databases,2007,1(2):141-259

[10] 寿秀香.基于C/S结构的教职工管理信息系统的设计与实现[J].黑龙江科技信息，2008，（31）55

[11] 张立科.java信息系统管理开发[M].北京：人民邮电出版社.

[12] 邓子云.JSP网络编程从基础到实践[M].北京：电子工业出版社.

[13] 朱涛江.MySql权威指南[M].中国电力出版社.2003.

[14] 郝玉龙.JavaEE编程技术[M].北京：北京交通大学出版社.

[15] 李清森，刘宇，侯玉凤 .浅谈高校铝窗综合管理.工作研究.2002.

[16]（美）Bruce Eckel著，陈昊鹏译，Java编程思想（第三版）［Ｍ]．北京：机械工业出版社，2007.6

[17] 李建中，王珊.《数据库系统原理（第2版）》电子工业出版社.2004.9

[18] 张长富，黄中敏．JavaScript动态网页编程实例手册［Ｍ］．北京：海洋出版社，2005：196-239

[19] 艾灵仙. 高校系级网站构建平台的设计与实现.[J]. 科技信息-2008年16期

    

致 谢

    本次设计历时三个月。在本次毕业设计中，能够基本顺利的完成任务，是与李光辉老师和殷红涛老师的耐心指导分不开的。两位老师无论是在毕业设计过程中，还是在论文完成中都给予了我极大的帮助。同时，两位老师认真负责的工作态度，严谨的治学精神和深厚的理论水平都使我受益匪浅。他们勤奋严谨的教学态度也给我留下了极为深刻的印象。我从老师身上学到了很多东西。在理论上还是在实践中，我能力都得到不少的提高，这对于我以后的工作和学习都是一种巨大的帮助，在此，特向两位老师表示由衷的感谢，最后还得感谢校内老师闫宏印老师耐心的帮我修改论文。

    通过这次毕业设计的整个开发过程，我对系统开发过程从需求分析到具体功能实现，再到最终测试和维护的理解有了很大的进步，让我对系统开发有了更深层次的认识。现在我的动手能力和独立解决问题的能力也得到了很大的锻炼和提高，这是这次毕业设计最好的收获。

    最后，在整个系统开发过程中，我身边的同学和朋友给了我很多的建议，让我很快的确定了系统的业务逻辑。我再次向他们表示衷心的感谢。

外文原文

Database Management Systems (DBMSs) are a ubiquitous and critical component of modern computing, and the result of decades of research and development in both academia and industry. Historically, DBMSs were among the earliest multi-user server systems to be developed, and thus pioneered many systems design techniques for scalability and reliability now in use in many other contexts. While many of the algorithms and abstractions used by a DBMS are textbook material, there has been relatively sparse coverage in the literature of the systems design issues that make a DBMS work.This paper presents an architectural discussion of DBMS design principles, including process models, parallel architecture, storage system design, transaction system implementation, query processor and optimizer architectures, and typical shared components and utilities. Successful commercial and open-source systems are used as points of reference, particularly when multiple alternative designs have been adopted by different groups.

Database Management Systems (DBMSs) are complex, mission-critical software systems. Today’s DBMSs embody decades of academic and industrial research and intense corporate software development. Database systems were among the earliest widely deployed online server systems and, as such, have pioneered design solutions spanning not only data management, but also applications, operating systems, and networked services. The early DBMSs are among the most influential software systems in computer science, and the ideas and implementation issues pioneered for DBMSs are widely copied and reinvented.

For a number of reasons, the lessons of database systems architecture are not as broadly known as they should be. First, the applied database systems community is fairly small. Since market forces only support a few competitors at the high end, only a handful of successful DBMS implementations exist. The community of people involved in designing and implementing database systems is tight: many attended the same schools, worked on the same in fluential research projects, and collaborated on the same commercial products. Second, academic treatment of database systems often ignores architectural issues. Textbook

presentations of database systems traditionally focus on algorithmic and theoretical issues  which are natural to teach, study, and test without a holistic discussion of system architecture in full implementations. In sum, much conventional wisdom about how to build database systems is available, but little of it has been written down or communicated broadly. In this paper, we attempt to capture the main architectural aspects of modern database systems, with a discussion of advanced topics. Some of these appear in the literature, and we provide references where appropriate. Other issues are buried in product manuals, and some are simply part of the oral tradition of the community. Where applicable, we use commercial and open-source systems as examples of the various architectural forms discussed. Space prevents, however, the enumeration of the exceptions and finer nuances that have found their way into these multi-million line code bases, most of which are well over a decade old. Our goal here is to focus on overall system design and stress issues not typically discussed in textbooks, providing useful context for more widely known algorithms and concepts. We assume that the reader is familiar with textbook database systems material and with the basic facilities of modern operating systems such as UNIX, Linux, or Windows. After introducing the high-level architecture of a DBMS in the next section, we provide a number of references to background reading on each of the components in Section 1.2.

 The most mature and widely used database systems in production today are relational database management systems (RDBMSs). These systems can be found at the core of much of the world’s application infrastructure including e-commerce, medical records, billing, human resources, payroll, customer relationship management and supply chain management, to name a few. The advent of web-based commerce and community-oriented sites has only increased the volume and breadth of their use. Relational systems serve as the repositories of record behind nearly all online transactions and most online content management systems (blogs, wikis, social networks, and the like). In addition to being important software infrastructure, relational database systems serve as a well-understood point of reference for new extensions and revolutions in database systems that may arise in the future. As a result, we focus on relational database systems throughout this paper.

      At heart, a typical RDBMS has five main components, as illustrated in Figure 1.1. As an introduction to each of these components and the way they fit together, we step through the life of a query in a database system. This also serves as an overview of the remaining sections of the paper.

Consider a simple but typical database interaction at an airport, in which a gate agent clicks on a form to request the passenger list for a flight. This button click results in a single-query transaction that works roughly as follows:

1. The personal computer at the airport gate (the“client”) calls an API that in turn communicates over a network to establish a connection with the Client Communications Manager of a DBMS (top of Figure 1.1). In some cases, this connection is established between the client and the database server directly, e.g., via the ODBC or JDBC connectivity protocol. This arrangement is termed a “two-tier” or “client-server” system. In other cases, the client may communicate with a“middle-tier server” (a web server, transaction processing monitor, or the like), which in turn uses a protocol to proxy the communication between the client and the DBMS. This is usually called a “three-tier”system. In many webbased scenarios there is yet another “application server” tier between the web server and the DBMS, resulting in four tiers. Given these various options, a typical DBMS needs to be compatible with many different connectivity protocols used by various client drivers and middleware systems. At base, however, the responsibility of the DBMS’client communications manager in all these protocols is roughly the same: to establish and remember the connection state for the caller (be it a client or a middleware server), to respond to SQL commands from the caller, and to return both data and control messages (result codes, errors, etc.) as appropriate. In our simple example, the communications manager would establish the security credentials of the client, set up state to remember the details of the new connection and the current SQL command across calls, and forward the client’s first request deeper into the DBMS to be processed.

2. Upon receiving the client’s first SQL command, the DBMS must assign a “thread of computation” to the command. It must also make sure that the thread’s data and control outputs are connected via the communications manager to the client. These tasks are the job of the DBMS Process Manager (left side of Figure 1.1). The most important decision that the DBMS needs to make at this stage in the query regards admission control: whether the system should begin processing the query immediately, or defer execution until a time when enough system resources are available to devote to this query. We discuss Process Management in detail in Section 2.

3. Once admitted and allocated as a thread of control, the gate agent’s query can begin to execute. It does so by invoking the code in the Relational Query Processor (center, Figure 1.1). This set of modules checks that the user is authorized to run the query, and compiles the user’s SQL query text into an internal query plan. Once compiled, the resulting query plan

is handled via the plan executor. The plan executor consists of a suite of “operators” (relational algorithm implementations) for executing any query. Typical operators implement

relational query processing tasks including joins, selection, projection, aggregation, sorting and so on, as well as calls to request data records from lower layers of the system. In our example query, a small subset of these operators — as assembled by the query optimization process — is invoked to satisfy the gate agent’s query. We discuss the query processor in Section 4.

4. At the base of the gate agent’s query plan, one or more operators exist to request data from the database. These operators make calls to fetch data from the DBMS’ Transactional Storage Manager (Figure 1.1, bottom), which manages all data access (read) and manipulation (create, update, delete) calls. The storage system includes algorithms and data structures for organizing and accessing data on disk (“access methods”), including basic structures like tables and indexes. It also includes a buffer management module that decides when and what data to transfer between disk and memory buffers. Returning to our example, in the course of accessing data in the access methods, the gate agent’s query must invoke the transaction management code to ensure the well-known “ACID” properties of transactions (discussed in more detail in Section 5.1). Before accessing data, locks are acquired from a lock manager to ensure correct execution in the face of other concurrent queries. If the gate agent’s query involved updates to the database, it would interact with the log manager to ensure that the transaction was durable if committed, and fully undone if aborted.

In Section 5, we discuss storage and buffer management in more detail; Section 6 covers the transactional consistency architecture.

5. At this point in the example query’s life, it has begun to access data records, and is ready to use them to compute results for the client. This is done by “unwinding the stack” of activities we described up to this point. The access methods return control to the query executor’s operators, which orchestrate the computation of result tuples from database data; as result tuples are generated, they are placed in a buffer for the client communications manager, which ships the results back to the caller. For large result sets, the client typically will make additional calls to fetch more data incrementally from the query, resulting in multiple iterations through the communications manager, query executor, and storage manager. In our simple example, at the end of the query the transaction is completed and the connection closed; this results in the transaction manager cleaning up state for the transaction, the process manager freeing any control structures for the query, and the communications manager cleaning up communication state for the connection.

The previous sections stressed the macro-architectural design issues in a DBMS. We now begin a sequence of sections discussing design at a somewhat finer grain, addressing each of the main DBMS components in turn. Following our discussion in Section 1.1, we start at the top of the system with the Query Processor, and in subsequent sections move down into storage management, transactions, and utilities.

A relational query processor takes a declarative SQL statement, validates it, optimizes it into a procedural dataflow execution plan, and (subject to admission control) executes that dataflow program on behalf of a client program. The client program then fetches (“pulls”) the

result tuples, typically one at a time or in small batches. The major components of a relational query processor are shown in Figure 1.1. In this section, we concern ourselves with both the query processor and some non-transactional aspects of the storage manager’s access methods. In general, relational query processing can be viewed as a single-user, single-threaded task. Concurrency control is managed transparently by lower layers of the system, as described in Section 5. The only exception to this rule is when the DBMS must explicitly “pin” and “unpin” buffer pool pages while operating on them so that they remain resident in memory during brief, critical operations as we discuss in Section 4.4.5.

In this section we focus on the common-case SQL commands: Data Manipulation Language (DML) statements including SELECT, INSERT, UPDATE, and DELETE. Data finition Language (DDL) statements such as CREATE TABLE and CREATE INDEX are typically not processed by the query optimizer. These statements are usually implemented procedurally in static DBMS logic through explicit calls to the storage engine and catalog manager (described in Section 6.1). Some products have begun optimizing a small subset of DDL statements as well and we expect this trend to continue.

Two basic types of DBMS storage managers are in commercial use today: either (1) the DBMS interacts directly with the low-level blockmode device drivers for the disks (often called raw-mode access), or (2) the DBMS uses standard OS le system facilities. This decision affects the DBMS’s ability to control storage in both space and time. We consider these two dimensions in turn, and proceed to discuss the use of the storage hierarchy in more detail.

In practice, database systems and the development teams that implement and maintain them do break down into independent components with documented interfaces between them. This is particularly true of the interface between the relational query processor and the transactional storage engine. Inmost commercial systems these components are written by different teams and have well-defined interfaces between them.

In this section, we cover a number of shared components and utilities that are present in nearly all commercial DBMS, but rarely discussed in the literature.

As should be clear from this paper, modern commercial database systems are grounded both in academic research and in the experiences of developing industrial-strength products for high-end customers. The task of writing and maintaining a high-performance, fully functional relational DBMS from scratch is an enormous investment in time and energy. Many of the lessons of relational DBMSs, however, translate over to new domains. Web services, network-attached storage, text and e-mail repositories, notification services, and network monitors can all benefit from DBMS research and experience. Data-intensive services are at the core of computing today, and knowledge of database system design is a skill that is broadly applicable, both inside and outside the halls of the main database shops. These new directions raise a number of research problems in database management as well, and point the way to new interactions between the database community and other areas of computing.

The authors would like to thank Rob von Behren, Eric Brewer, Paul Brown, Amol Deshpande, Cesar Galindo-Legaria, Jim Gray, Wei Hong, Matt Huras, Lubor Kollar, Ganapathy Krishnamoorthy, Bruce Lindsay, Guy Lohman, S. Muralidhar, Pat Selinger, Mehul Shah, and Matt Welsh for background information and comments on early drafts of this paper.

     

中文翻译

    数据库管理系统（DBMS）是现代计算的无处不在的重要组成部分，是几十年的研究和发展，学术界和工业界的结果。从历史上看，数据库管理系统是待开发的最早的多用户服务器系统，从而开创了现在使用在其他情况下很多系统设计技术的可扩展性和可靠性。虽然许多可使用的数据库管理系统的算法和抽象是教科书的材料，但出现了使DBMS的工作文献相对稀疏覆盖的系统设计问题。本文介绍了数据库管理系统的设计原则，包括过程模型，并行架构，存储系统设计，交易系统实施，查询处理器和优化的架构，以及典型的共享组件和实用程序的体系结构的讨论。尤其是当多个备选设计已通过不同的组，成功的商业和开源系统作为参考点。

    数据库管理系统（DBMS）是复杂的，任务关键型软件系统。今天的DBMS是几十年的学术和工业研究和激烈的企业软件开发成果。数据库系统是最早广泛使用的在线服务器系统之间的，因此，已率先设计解决方案涵盖不仅数据管理，而且还有应用程序，操作系统和网络服务。在计算机科学中早期的DBMS是最有影响力的软件系统，并率先为数据库管理系统的思路和实施问题提供广泛复制和改造。

    对于一些原因，数据库系统体系结构的教训并不广泛称。首先，应用的数据库系统中的社区是相当小的。由于市场力量只支持在高端一些的竞争对手，只有少数成功的DBMS实现的存在。人参与设计和实施数据库系统的社会紧张：许多参加了同一所学校，在fluential研究项目上工作一样，并合作在同一个商业产品。二，学术处理数据库系统往往忽略了结构问题。教科书数据库系统的演示传统专注于算法和理论问题 - 这是自然的教导，学习和测试 - 无需系统架构完全实现全面的讨论。总之，关于如何构建数据库系统许多传统智慧是可用的，但一点已经写下来或广泛地传达。

    在本文中，我们试图捕捉现代数据库系统的主要架构方面，借助先进的议题进行了讨论。其中的一些出现在文献中，我们提供的引用其中合适的。其他问题都在产品使用说明书，有的只是社会的口头传统的一部分。在适用情况下，我们使用的商业和开放源代码系统作为讨论的各种建筑形式的例子。但是，已经发现他们的方式进入这些数百万行的代码库的异常和更精细的细微差别的枚举，其中大部分是超过十年的历史。我们的目标是把重点放在课本中通常不讨论，更广为人知的算法和概念提供有用的背景下整体系统的设计和压力问题。我们假设读者熟悉教材数据库系统材料（例如，[72]或[83]）

并与现代操作系统如UNIX，Linux或Windows的基本设施。引入数据库管理系统的高级体系结构在下一节后，我们提供了一些参考背景阅读每节1.2的组件的。

    在生产中最成熟和广泛使用的数据库系统是当今的关系型数据库管理系统（RDBMS）。这些系统可以在世界上大部分的应用程序基础设施，包括电子商务，病历，计费，人力资源，工资单，客户关系管理和供应链管理，仅举几例的核心就可以发现。基于Web的电子商务和社区为导向的网站的出现，不仅增加了其使用量和广度。关系系统作为记录的存储库背后几乎所有的网上交易和网上大多数内容管理系统（博客，维基，社交网络，等等）。除了作为重要的软件基础设施，关系数据库系统作为对可能出现在未来的新的扩展和革命的数据库系统的参考一个很好理解的点。因此，我们专注于关系型数据库系统整篇文章。

    一个典型的关系型数据库有五个主要部分组成，如图1.1。作为一个介绍这些组件和它们组合在一起的方式，我们通过查询在数据库系统中的生命周期步骤。这也可作为本文的其余部分的概述。

    考虑一个简单的，但典型的数据库交互在机场，其中一门代理单击窗体，要求乘客在名单的航班上。此按钮点击会导致单查询事务，工程大致如下：

    (1) 在机场门口的个人计算机（“客户”）调用一个API，它反过来通信通过网络建立与数据库管理系统的客户端通信管理器的连接。在某些情况下，这种连接建立客户端和直接数据库服务器之间，例如，通过ODBC或JDBC连接协议。这种安排被称为“双层”或“客户端 - 服务器”体系。在其他情况下，客户端可以与一个“中间层服务器”（Web服务器，事务处理监视器，或类似的），这反过来又使用协议代理客户机和数据库管理系统之间的通信进行通信。这通常被称为“三级制”。在许多基于网络的情况下有Web服务器和数据库管理系统之间的又一个“应用程序服务器”层，造成四层。鉴于这些不同的选项，一个典型的数据库管理系统的需求要与使用的各种客户端驱动程序和中间件系统的许多不同的连接协议兼容。但是，在DBMS“客户端通信经理在所有这些协议的责任是大致相同：建立和记住的连接状态为调用者（无论是客户端还是中间件服务器），以从SQL命令响应来电者，并以数据和控制信息（结果代码，错误等），返回（如适用）。在我们的简单例子中，通信管理器将建立客户端的安全凭据，设立国有记住在调用新的连接和当前的SQL命令的详细信息，并转发客户端的第一个要求深入到要处理的数据库管理系统。

    (2) 在收到客户端的第一个SQL命令时，DBMS必须指定一个“线程计算”的命令。它还必须确保线程的数据和控制输出通过通信管理器连接到客户端。这些任务是DBMS的进程管理器的工作。该数据库管理系统需要在本阶段在查询中的最重要的决定对于准入控制：系统是否应立即开始处理查询，或推迟执行，直到当有足够的系统资源可以投入到这个查询的时间。我们讨论过程管理中的细节在第2节。

    (3) 一旦录取，并分配为控制线程，门代理的查询可以开始执行。它通过调用代码中的关系查询处理器这样做。这组模块检查该用户是否被授权来运行查询，并编译用户的SQL查询文本转换成一个内部查询计划。编译后，生成的查询计划

通过该计划执行人处理。该计划由遗嘱执行人执行的任何查询了一套“经营者”（关系算法实现）的。典型运营商实施关系查询处理的任务，包括联接，选择，投影，聚合，排序等等，以及呼叫从系统的较低层请求数据的记录。在我们的示例查询中，这些运营商的一小部分 - 作为组装的查询优化过程 - 被调用，以满足门代理的查询。我们讨论了查询处理器在第4节。

    (4) 在栅极代理的查询计划的基础上，一个或多个运营商存在以请求来自数据库的数据。这些运营商拨打电话，以获取从数据库管理系统“事务性存储管理器的数据，管理所有的数据访问（读取）和操作（创建，更新，删除）调用。该存储系统包括算法和数据结构的组织和访问磁盘上的数据（“访问方法”），包括像表和索引的基本结构。它还包括决定何时以及哪些数据磁盘和存储器缓冲区之间传输的缓冲器管理模块。回到我们的例子中，在接入方式访问数据的过程中，门代理的查询必须调用事务管理代码，以确保交易的著名的“ACID”属性[30]。在访问数据时，锁是从锁管理器获取的，以确保正确执行在其他并发查询的脸。如果门代理的查询涉及对数据库的更新，它会与日志管理器进行交互，以确保交易是持久的，如果承诺了，如果流产完全撤消。

在第5节，我们讨论存储和缓冲管理更加详细;第6节涵盖了事务的一致性架构。

    (5) 此时，在该示例查询的寿命，它已经开始存取数据的记录，并准备利用它们来计算的结果的客户端。这是通过“解除堆叠”，我们描述了这一点活动完成。访问方法将控制返回给查询执行的运营商，它从编排数据库中的数据结果元组的计算;作为生成结果的元组，它们被放置在一个缓冲区为客户端通信管理器，船舶结果返回给调用者。对于大的结果集，客户端通常会拨打其它电话从查询获取增量更多的数据，从而通过通信管理器，查询执行器和存储经理多次迭代。在我们的简单的例子，在查询结束交易完成后，连接关闭;这将导致在事务管理器清理状态进行交易，进程管理器释放任何控制结构的查询，以及公关经理清理通信状态的连接。

    在上一节强调在DBMS中的宏观架构设计问题。我们现在开始讨论设计在稍微更细的颗粒，解决逐一主要的DBMS组件的部分序列。下面我们在1.1节的讨论，我们开始在系统中查询处理器的顶部，并在随后的章节中向下移动到存储管理，事务和公共事业。

    一个关系查询处理器需要声明的SQL语句，验证它，优化它变成一个程序上的数据流执行计划，并（受准入控制）代表一个客户端程序的执行该数据流的程序。客户端程序，然后取（“拉”）的结果元组，通常一次一个或小批量。一个关系查询处理器的主要部件如图1.1所示。在本节中，我们关注两个查询的存储管理器的访问方法的处理器和一些非事务方面。在一般情况下，关系查询处理可以被看作是一个单用户，单线程任务。并发控制是透明管理，通过系统的较低层，如第5节所述，唯一的例外是当DBMS必须明确“针”和“取消固定”缓冲池页面，同时对他们操作，让他们一直驻留在在短暂的，关键操作内存正如我们在第4.4.5节讨论。

    在本节中，我们着眼于共同的情况下SQL命令：数据操作语言（DML）语句，包括SELECT，INSERT，UPDATE和DELETE。数据定义语言（DDL）语句，例如CREATE TABLE和CREATE INDEX通常不会被查询优化处理。这些陈述通常是通过显式调用存储引擎和目录管理器（6.1节所述）程序上实现静态数据库管理系统的逻辑。部分产品已开始优化DDL语句的一个很小的子集，以及我们预计这一趋势将持续下去。存储管理两种基本类型的DBMS存储经理都在今日有商业用途：要么（1）数据库管理系统直接交互的磁盘（通常称为原始模式接入），或（2）数据库管理系统使用标准的操作系统的底层blockmode设备驱动程序文件系统设备。这个决定会影响DBMS的在空间和时间控制存储能力。我们认为这两个维度反过来，进而详细讨论了利用存储层次结构。

    在实际应用中，数据库系统 - 以及实施和维护他们的开发团队 - 不要分解成它们之间记录的接口独立的组件。这是特别真实的关系查询处理器和事务存储引擎之间的界面。这些组件都写由不同的团队和内心深处的商用系统已经明确定义它们之间的接口。

    在本节中，我们将介绍一些共享组件和实用程序，存在于几乎所有的商业数据库管理系统，但在文献中很少讨论。

    应该从本文中明确，现代商业数据库系统无论是在学术研究还是开发工业级的产品，都为高端客户的经验。编写和维护一个高性能，全功能的关系型数据库管理系统从无到有的任务是需要一次巨大的投资和能量。许多关系型DBMS的成果，Web服务，网络附加存储，文本和电子邮件存储库，通知服务，以及网络监控可以从数据库管理系统的研究和经验中获益。数据密集型服务在当今计算的核心，数据库系统设计知识是一种技能，是广泛适用的犹如内外的主数据库商店大厅。一些数据库管理的研究问题提出了这些新的方向，并指出该方法从数据库界和计算等领域之间的新的交互。

    作者要感谢罗布·冯·Behren，埃里克·布鲁尔，保罗·布朗，阿莫尔德什潘德，塞萨尔加林-Legaria，吉姆·格雷，魏宏，马特Huras，Lubor Kollar，Ganapathy Krishnamoorthy都是布鲁斯·林赛，盖伊洛曼，S. Muralidhar，帕特泽林格，MEHUL沙阿和马特威尔士的背景信息和本文的早期草稿的意见。