教师工资管理系统-外文翻译

外文原文DatabaseManagementSystems(DBMSs)areaubiquitousandcriticalcomponentofmoderncomputing,andtheresultofdecadesofresearchanddevelopmentinbothacademiaandindustry.Historically,DBMSswereamongtheearliestmulti-userserversystemstobedeveloped,andthuspioneeredmanysystemsdesigntechniquesforscalabilityandreliabilitynowinuseinmanyothercontexts.WhilemanyofthealgorithmsandabstractionsusedbyaDBMSaretextbookmaterial,therehasbeenrelativelysparsecoverageintheliteratureofthesystemsdesignissuesthatmakeaDBMSwork.ThispaperpresentsanarchitecturaldiscussionofDBMSdesignprinciples,includingprocessmodels,parallelarchitecture,storagesystemdesign,transactionsystemimplementation,queryprocessorandoptimizerarchitectures,andtypicalsharedcomponentsandutilities.Successfulcommercialandopen-sourcesystemsareusedaspointsofreference,particularlywhenmultiplealternativedesignshavebeenadoptedbydifferentgroups.DatabaseManagementSystems(DBMSs)arecomplex,mission-criticalsoftwaresystems.TodaysDBMSsembodydecadesofacademicandindustrialresearchandintensecorporatesoftwaredevelopment.Databasesystemswereamongtheearliestwidelydeployedonlineserversystemsand,assuch,havepioneereddesignsolutionsspanningnotonlydatamanagement,butalsoapplications,operatingsystems,andnetworkedservices.TheearlyDBMSsareamongthemostinfluentialsoftwaresystemsincomputerscience,andtheideasandimplementationissuespioneeredforDBMSsarewidelycopiedandreinvented.Foranumberofreasons,thelessonsofdatabasesystemsarchitecturearenotasbroadlyknownastheyshouldbe.First,theapplieddatabasesystemscommunityisfairlysmall.Sincemarketforcesonlysupportafewcompetitorsatthehighend,onlyahandfulofsuccessfulDBMSimplementationsexist.Thecommunityofpeopleinvolvedindesigningandimplementingdatabasesystemsistight:manyattendedthesameschools,workedonthesameinfluentialresearchprojects,andcollaboratedonthesamecommercialproducts.Second,academictreatmentofdatabasesystemsoftenignoresarchitecturalissues.Textbookpresentationsofdatabasesystemstraditionallyfocusonalgorithmicandtheoreticalissueswhicharenaturaltoteach,study,andtestwithoutaholisticdiscussionofsystemarchitectureinfullimplementations.Insum,muchconventionalwisdomabouthowtobuilddatabasesystemsisavailable,butlittleofithasbeenwrittendownorcommunicatedbroadly.Inthispaper,weattempttocapturethemainarchitecturalaspectsofmoderndatabasesystems,withadiscussionofadvancedtopics.Someoftheseappearintheliterature,andweprovidereferenceswhereappropriate.Otherissuesareburiedinproductmanuals,andsomearesimplypartoftheoraltraditionofthecommunity.Whereapplicable,weusecommercialandopen-sourcesystemsasexamplesofthevariousarchitecturalformsdiscussed.Spaceprevents,however,theenumerationoftheexceptionsandfinernuancesthathavefoundtheirwayintothesemulti-millionlinecodebases,mostofwhicharewelloveradecadeold.Ourgoalhereistofocusonoverallsystemdesignandstressissuesnottypicallydiscussedintextbooks,providingusefulcontextformorewidelyknownalgorithmsandconcepts.WeassumethatthereaderisfamiliarwithtextbookdatabasesystemsmaterialandwiththebasicfacilitiesofmodernoperatingsystemssuchasUNIX,Linux,orWindows.Afterintroducingthehigh-levelarchitectureofaDBMSinthenextsection,weprovideanumberofreferencestobackgroundreadingoneachofthecomponentsinSection1.2.Themostmatureandwidelyuseddatabasesystemsinproductiontodayarerelationaldatabasemanagementsystems(RDBMSs).Thesesystemscanbefoundatthecoreofmuchoftheworldsapplicationinfrastructureincludinge-commerce,medicalrecords,billing,humanresources,payroll,customerrelationshipmanagementandsupplychainmanagement,tonameafew.Theadventofweb-basedcommerceandcommunity-orientedsiteshasonlyincreasedthevolumeandbreadthoftheiruse.Relationalsystemsserveastherepositoriesofrecordbehindnearlyallonlinetransactionsandmostonlinecontentmanagementsystems(blogs,wikis,socialnetworks,andthelike).Inadditiontobeingimportantsoftwareinfrastructure,relationaldatabasesystemsserveasawell-understoodpointofreferencefornewextensionsandrevolutionsindatabasesystemsthatmayariseinthefuture.Asaresult,wefocusonrelationaldatabasesystemsthroughoutthispaper.Atheart,atypicalRDBMShasfivemaincomponents,asillustratedinFigure1.1.Asanintroductiontoeachofthesecomponentsandthewaytheyfittogether,westepthroughthelifeofaqueryinadatabasesystem.Thisalsoservesasanoverviewoftheremainingsectionsofthepaper.Considerasimplebuttypicaldatabaseinteractionatanairport,inwhichagateagentclicksonaformtorequestthepassengerlistforaflight.Thisbuttonclickresultsinasingle-querytransactionthatworksroughlyasfollows:1.Thepersonalcomputerattheairportgate(the“client”)callsanAPIthatinturncommunicatesoveranetworktoestablishaconnectionwiththeClientCommunicationsManagerofaDBMS(topofFigure1.1).Insomecases,thisconnectionisestablishedbetweentheclientandthedatabaseserverdirectly,e.g.,viatheODBCorJDBCconnectivityprotocol.Thisarrangementistermeda“two-tier”or“client-server”system.Inothercases,theclientmaycommunicatewitha“middle-tierserver”(awebserver,transactionprocessingmonitor,orthelike),whichinturnusesaprotocoltoproxythecommunicationbetweentheclientandtheDBMS.Thisisusuallycalleda“three-tier”system.Inmanywebbasedscenariosthereisyetanother“applicationserver”tierbetweenthewebserverandtheDBMS,resultinginfourtiers.Giventhesevariousoptions,atypicalDBMSneedstobecompatiblewithmanydifferentconnectivityprotocolsusedbyvariousclientdriversandmiddlewaresystems.Atbase,however,theresponsibilityoftheDBMSclientcommunicationsmanagerinalltheseprotocolsisroughlythesame:toestablishandremembertheconnectionstateforthecaller(beitaclientoramiddlewareserver),torespondtoSQLcommandsfromthecaller,andtoreturnbothdataandcontrolmessages(resultcodes,errors,etc.)asappropriate.Inoursimpleexample,thecommunicationsmanagerwouldestablishthesecuritycredentialsoftheclient,setupstatetorememberthedetailsofthenewconnectionandthecurrentSQLcommandacrosscalls,andforwardtheclientsfirstrequestdeeperintotheDBMStobeprocessed.2.UponreceivingtheclientsrstSQLcommand,theDBMSmustassigna“threadofcomputation”tothecommand.Itmustalsomakesurethatthethreadsdataandcontroloutputsareconnectedviathecommunicationsmanagertotheclient.ThesetasksarethejoboftheDBMSProcessManager(leftsideofFigure1.1).ThemostimportantdecisionthattheDBMSneedstomakeatthisstageinthequeryregardsadmissioncontrol:whetherthesystemshouldbeginprocessingthequeryimmediately,ordeferexecutionuntilatimewhenenoughsystemresourcesareavailabletodevotetothisquery.WediscussProcessManagementindetailinSection2.3.Onceadmittedandallocatedasathreadofcontrol,thegateagentsquerycanbegintoexecute.ItdoessobyinvokingthecodeintheRelationalQueryProcessor(center,Figure1.1).Thissetofmoduleschecksthattheuserisauthorizedtorunthequery,andcompilestheusersSQLquerytextintoaninternalqueryplan.Oncecompiled,theresultingqueryplanishandledviatheplanexecutor.Theplanexecutorconsistsofasuiteof“operators”(relationalalgorithmimplementations)forexecutinganyquery.Typicaloperatorsimplementrelationalqueryprocessingtasksincludingjoins,selection,projection,aggregation,sortingandsoon,aswellascallstorequestdatarecordsfromlowerlayersofthesystem.Inourexamplequery,asmallsubsetoftheseoperatorsasassembledbythequeryoptimizationprocessisinvokedtosatisfythegateagentsquery.WediscussthequeryprocessorinSection4.4.Atthebaseofthegateagentsqueryplan,oneormoreoperatorsexisttorequestdatafromthedatabase.TheseoperatorsmakecallstofetchdatafromtheDBMSTransactionalStorageManager(Figure1.1,bottom),whichmanagesalldataaccess(read)andmanipulation(create,update,delete)calls.Thestoragesystemincludesalgorithmsanddatastructuresfororganizingandaccessingdataondisk(“accessmethods”),includingbasicstructuresliketablesandindexes.Italsoincludesabuffermanagementmodulethatdecideswhenandwhatdatatotransferbetweendiskandmemorybuffers.Returningtoourexample,inthecourseofaccessingdataintheaccessmethods,thegateagentsquerymustinvokethetransactionmanagementcodetoensurethewell-known“ACID”propertiesoftransactions(discussedinmoredetailinSection5.1).Beforeaccessingdata,locksareacquiredfromalockmanagertoensurecorrectexecutioninthefaceofotherconcurrentqueries.Ifthegateagentsqueryinvolvedupdatestothedatabase,itwouldinteractwiththelogmanagertoensurethatthetransactionwasdurableifcommitted,andfullyundoneifaborted.InSection5,wediscussstorageandbuffermanagementinmoredetail;Section6coversthetransactionalconsistencyarchitecture.5.Atthispointintheexamplequeryslife,ithasbeguntoaccessdatarecords,andisreadytousethemtocomputeresultsfortheclient.Thisisdoneby“unwindingthestack”ofactivitieswedescribeduptothispoint.Theaccessmethodsreturncontroltothequeryexecutorsoperators,whichorchestratethecomputationofresulttuplesfromdatabasedata;asresulttuplesaregenerated,theyareplacedinabufferfortheclientcommunicationsmanager,whichshipstheresultsbacktothecaller.Forlargeresultsets,theclienttypicallywillmakeadditionalcallstofetchmoredataincrementallyfromthequery,resultinginmultipleiterationsthroughthecommunicationsmanager,queryexecutor,andstoragemanager.Inoursimpleexample,attheendofthequerythetransactioniscompletedandtheconnectionclosed;thisresultsinthetransactionmanagercleaningupstateforthetransaction,theprocessmanagerfreeinganycontrolstructuresforthequery,andthecommunicationsmanagercleaningupcommunicationstatefortheconnection.Theprevioussectionsstressedthemacro-architecturaldesignissuesinaDBMS.Wenowbeginasequenceofsectionsdiscussingdesignatasomewhatfinergrain,addressingeachofthemainDBMScomponentsinturn.FollowingourdiscussioninSection1.1,westartatthetopofthesystemwiththeQueryProcessor,andinsubsequentsectionsmovedownintostoragemanagement,transactions,andutilities.ArelationalqueryprocessortakesadeclarativeSQLstatement,validatesit,optimizesitintoaproceduraldataflowexecutionplan,and(subjecttoadmissioncontrol)executesthatdataflowprogramonbehalfofaclientprogram.Theclientprogramthenfetches(“pulls”)theresulttuples,typicallyoneatatimeorinsmallbatches.ThemajorcomponentsofarelationalqueryprocessorareshowninFigure1.1.Inthissection,weconcernourselveswithboththequeryprocessorandsomenon-transactionalaspectsofthestoragemanagersaccessmethods.Ingeneral,relationalqueryprocessingcanbeviewedasasingle-user,single-threadedtask.Concurrencycontrolismanagedtransparentlybylowerlayersofthesystem,asdescribedinSection5.TheonlyexceptiontothisruleiswhentheDBMSmustexplicitly“pin”and“unpin”bufferpoolpageswhileoperatingonthemsothattheyremainresidentinmemoryduringbrief,criticaloperationsaswediscussinSection4.4.5.Inthissectionwefocusonthecommon-caseSQLcommands:DataManipulationLanguage(DML)statementsincludingSELECT,INSERT,UPDATE,andDELETE.DatafinitionLanguage(DDL)statementssuchasCREATETABLEandCREATEINDEXaretypicallynotprocessedbythequeryoptimizer.ThesestatementsareusuallyimplementedprocedurallyinstaticDBMSlogicthroughexplicitcallstothestorageengineandcatalogmanager(describedinSection6.1).SomeproductshavebegunoptimizingasmallsubsetofDDLstatementsaswellandweexpectthistrendtocontinue.TwobasictypesofDBMSstoragemanagersareincommercialusetoday:either(1)theDBMSinteractsdirectlywiththelow-levelblockmodedevicedriversforthedisks(oftencalledraw-modeaccess),or(2)theDBMSusesstandardOSlesystemfacilities.ThisdecisionaffectstheDBMSsabilitytocontrolstorageinbothspaceandtime.Weconsiderthesetwodimensionsinturn,andproceedtodiscusstheuseofthestoragehierarchyinmoredetail.Inpractice,databasesystemsandthedevelopmentteamsthatimplementandmaintainthemdobreakdownintoindependentcomponentswithdocumentedinterfacesbetweenthem.Thisisparticularlytrueoftheinterfacebetweentherelationalqueryprocessorandthetransactionalstorageengine.Inmostcommercialsystemsthesecomponentsarewrittenbydifferentteamsandhavewell-denedinterfacesbetweenthem.Inthissection,wecoveranumberofsharedcomponentsandutilitiesthatarepresentinnearlyallcommercialDBMS,butrarelydiscussedintheliterature.Asshouldbeclearfromthispaper,moderncommercialdatabasesystemsaregroundedbothinacademicresearchandintheexperiencesofdevelopingindustrial-strengthproductsforhigh-endcustomers.Thetaskofwritingandmaintainingahigh-performance,fullyfunctionalrelationalDBMSfromscratchisanenormousinvestmentintimeandenergy.ManyofthelessonsofrelationalDBMSs,however,translateovertonewdomains.Webservices,network-attachedstorage,textande-mailrepositories,notificationservices,andnetworkmonitorscanallbenefitfromDBMSresearchandexperience.Data-intensiveservicesareatthecoreofcomputingtoday,andknowledgeofdatabasesystemdesignisaskillthatisbroadlyapplicable,bothinsideandoutsidethehallsofthemaindatabaseshops.Thesenewdirectionsraiseanumberofresearchproblemsindatabasemanagementaswell,andpointthewaytonewinteractionsbetweenthedatabasecommunityandotherareasofcomputing.TheauthorswouldliketothankRobvonBehren,EricBrewer,PaulBrown,AmolDeshpande,CesarGalindo-Legaria,JimGray,WeiHong,MattHuras,LuborKollar,GanapathyKrishnamoorthy,BruceLindsay,GuyLohman,S.Muralidhar,PatSelinger,MehulShah,andMattWelshforbackgroundinformationandcommentsonearlydraftsofthispaper.中文翻译数据库管理系统（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。在访问数据时，锁是从锁管理器获取的，以确保正确执行在其他并发查询的脸。如果门代理的查询涉及对