酒店餐饮管理系统-外文翻译

外文及翻译附录A外文原文AHISTORICALPERSPECTIVEFromtheearliestdaysofcomputers,storingandmanipulatingdatahavebeenamajorapplicationfocus.Thefirstgeneral-purposeDBMSwasdesignedbyCharlesBachmanatGeneralElectricintheearly1960sandwascalledtheIntegratedDataStore.Itformedthebasisforthenetworkdatamodel,whichwasstandardizedbytheConferenceonDataSystemsLanguages(CODASYL)andstronglyinfluenceddatabasesystemsthroughthe1960s.BachmanwasthefirstrecipientofACMsTuringAward(thecomputerscienceequivalentofaNobelprize)forworkinthedatabasearea;hereceivedtheawardin1973.Inthelate1960s,IBMdevelopedtheInformationManagementSystem(IMS)DBMS,usedeventodayinmanymajorinstallations.IMSformedthebasisforanalternativedatarepresentationframeworkcalledthehierarchicaldatamodel.TheSABREsystemformakingairlinereservationswasjointlydevelopedbyAmericanAirlinesandIBMaroundthesametime,anditallowedseveralpeopletoaccessthesamedatathroughcomputernetwork.Interestingly,todaythesameSABREsystemisusedtopowerpopularWeb-basedtravelservicessuchasTravelocity!In1970,EdgarCodd,atIBMsSanJoseResearchLaboratory,proposedanewdatarepresentationframeworkcalledtherelationaldatamodel.Thisprovedtobeawatershedinthedevelopmentofdatabasesystems:itsparkedrapiddevelopmentofseveralDBMSsbasedontherelationalmodel,alongwitharichbodyoftheoreticalresultsthatplacedthefieldonafirmfoundation.Coddwonthe1981TuringAwardforhisseminalwork.Databasesystemsmaturedasanacademicdiscipline,andthepopularityofrelationalDBMSschangedthecommerciallandscape.Theirbenefitswerewidelyrecognized,andtheuseofDBMSsformanagingcorporatedatabecamestandardpractice.Inthe1980s,therelationalmodelconsolidateditspositionasthedominantDBMSparadigm,anddatabasesystemscontinuedtogainwidespreaduse.TheSQLquerylanguageforrelationaldatabases,developedaspartofIBMsSystemRproject,isnowthestandardquerylanguage.SQLwasstandardizedinthelate1980s,andthecurrentstandard,SQL-92,wasadoptedbytheAmericanNationalStandardsInstitute(ANSI)andInternationalStandardsOrganization(ISO).Arguably,themostwidelyusedformofconcurrentprogrammingistheconcurrentexecutionofdatabaseprograms(calledtransactions).Userswriteprogramsasiftheyaretoberunbythemselves,andtheresponsibilityforrunningthemconcurrentlyisgiventotheDBMS.JamesGraywonthe1999TuringawardforhiscontributionstothefieldoftransactionmanagementinaDBMS.Inthelate1980sandthe1990s,advanceshavebeenmadeinmanyareasofdatabasesystems.Considerableresearchhasbeencarriedoutintomorepowerfulquerylanguagesandricherdatamodels,andtherehasbeenabigemphasisonsupportingcomplexanalysisofdatafromallpartsofanenterprise.Severalvendors(e.g.,IBMsDB2,Oracle8,InformixUDS)haveextendedtheirsystemswiththeabilitytostorenewdatatypessuchasimagesandtext,andwiththeabilitytoaskmorecomplexqueries.Specializedsystemshavebeendevelopedbynumerousvendorsforcreatingdatawarehouses,consolidatingdatafromseveraldatabases,andforcarryingoutspecializedanalysis.Aninterestingphenomenonistheemergenceofseveralenterpriseresourceplanning(ERP)andmanagementresourceplanning(MRP)packages,whichaddasubstantiallayerofapplication-orientedfeaturesontopofaDBMS.WidelyusedpackagesincludesystemsfromBaan,Oracle,PeopleSoft,SAP,andSiebel.Thesepackagesidentifyasetofcommontasks(e.g.,inventorymanagement,humanresourcesplanning,financialanalysis)encounteredbyalargenumberoforganizationsandprovideageneralapplicationlayertocarryoutthesetasks.ThedataisstoredinarelationalDBMS,andtheapplicationlayercanbecustomizedtodifferentcompanies,leadingtolowerIntroductiontoDatabaseSystemsoverallcostsforthecompanies,comparedtothecostofbuildingtheapplicationlayerfromscratch.Mostsignificantly,perhaps,DBMSshaveenteredtheInternetAge.WhilethefirstgenerationofWebsitesstoredtheirdataexclusivelyinoperatingsystemsfiles,theuseofaDBMStostoredatathatisaccessedthroughaWebbrowserisbecomingwidespread.QueriesaregeneratedthroughWeb-accessibleformsandanswersareformattedusingamarkuplanguagesuchasHTML,inordertobeeasilydisplayedinabrowser.AllthedatabasevendorsareaddingfeaturestotheirDBMSaimedatmakingitmoresuitablefordeploymentovertheInternet.Databasemanagementcontinuestogainimportanceasmoreandmoredataisbroughton-line,andmadeevermoreaccessiblethroughcomputernetworking.Todaythefieldisbeingdrivenbyexcitingvisionssuchasmultimediadatabases,interactivevideo,digitallibraries,ahostofscientificprojectssuchasthehumangenomemappingeffortandNASAsEarthObservationSystemproject,andthedesireofcompaniestoconsolidatetheirdecision-makingprocessesandminetheirdatarepositoriesforusefulinformationabouttheirbusinesses.Commercially,databasemanage-mentsystemsrepresentoneofthelargestandmostvigorousmarketsegments.Thusthes-tudyofdatabasesystemscouldprovetoberichlyrewardinginmorewaysthanone!INTRODUCTIONTOPHYSICALDATABASEDESIGNLikeallotheraspectsofdatabasedesign,physicaldesignmustbeguidedbythenatureofthedataanditsintendeduse.Inparticular,itisimportanttounderstandthetypicalworkloadthatthedatabasemustsupport;theworkloadconsistsofamixofqueriesandupdates.Usersalsohavecertainrequirementsabouthowfastcertainqueriesorupdatesmustrunorhowmanytransactionsmustbeprocessedpersecond.Theworkloaddescriptionandusersperformancerequirementsarethebasisonwhichanumberofdecisionshavetobemadeduringphysicaldatabasedesign.Tocreateagoodphysicaldatabasedesignandtotunethesystemforperformanceinresponsetoevolvinguserrequirements,thedesignerneedstounderstandtheworkingsofaDBMS,especiallytheindexingandqueryprocessingtechniquessupportedbytheDBMS.Ifthedatabaseisexpectedtobeaccessedconcurrentlybymanyusers,orisadistributeddatabase,thetaskbecomesmorecomplicated,andotherfeaturesofaDBMScomeintoplay.DATABASEWORKLOADSThekeytogoodphysicaldesignisarrivingatanaccuratedescriptionoftheexpectedworkload.Aworkloaddescriptionincludesthefollowingelements:1.Alistofqueriesandtheirfrequencies,asafractionofallqueriesandupdates.2.Alistofupdatesandtheirfrequencies.3.Performancegoalsforeachtypeofqueryandupdate.Foreachqueryintheworkload,wemustidentify:Whichrelationsareaccessed.Whichattributesareretained(intheSELECTclause).Whichattributeshaveselectionorjoinconditionsexpressedonthem(intheWHEREclause)andhowselectivetheseconditionsarelikelytobe.Similarly,foreachupdateintheworkload,wemustidentify:Whichattributeshaveselectionorjoinconditionsexpressedonthem(intheWHEREclause)andhowselectivetheseconditionsarelikelytobe.Thetypeofupdate(INSERT,DELETE,orUPDATE)andtheupdatedrelation.ForUPDATEcommands,thefieldsthataremodifiedbytheupdate.Rememberthatqueriesandupdatestypicallyhaveparameters,forexample,adebitorcreditoperationinvolvesaparticularaccountnumber.Thevaluesoftheseparametersdetermineselectivityofselectionandjoinconditions.Updateshaveaquerycomponentthatisusedtofindthetargettuples.Thiscomponentcanbenefitfromagoodphysicaldesignandthepresenceofindexes.Ontheotherhand,updatestypicallyrequireadditionalworktomaintainindexesontheattributesthattheymodify.Thus,whilequeriescanonlybenefitfromthepresenceofanindex,anindexmayeitherspeeduporslowdownagivenupdate.Designersshouldkeepthistrade-offerinmindwhencreatingindexes.NEEDFORDATABASETUNINGAccurate,detailedworkloadinformationmaybehardtocomebywhiledoingtheinitialdesignofthesystem.Consequently,tuningadatabaseafterithasbeendesignedanddeployedisimportantwemustrefinetheinitialdesigninthelightofactualusagepatternstoobtainthebestpossibleperformance.Thedistinctionbetweendatabasedesignanddatabasetuningissomewhatarbitrary.Wecouldconsiderthedesignprocesstobeoveronceaninitialconceptualschemaisdesignedandasetofindexingandclusteringdecisionsismade.Anysubsequentchangestotheconceptualschemaortheindexes,say,wouldthenberegardedasatuningactivity.Alternatively,wecouldconsidersomerefinementoftheconceptualschema(andphysicaldesigndecisionsaffectedbythisrefinement)tobepartofthephysicaldesignprocess.Wherewedrawthelinebetweendesignandtuningisnotveryimportant.OVERVIEWOFDATABASETUNINGAftertheinitialphaseofdatabasedesign,actualuseofthedatabaseprovidesavaluablesourceofdetailedinformationthatcanbeusedtorefinetheinitialdesign.Manyoftheoriginalassumptionsabouttheexpectedworkloadcanbereplacedbyobservedusagepatterns;ingeneral,someoftheinitialworkloadspecificationwillbevalidated,andsomeofitwillturnouttobewrong.Initialguessesaboutthesizeofdatacanbereplacedwithactualstatisticsfromthesystemcatalogs(althoughthisinformationwillkeepchangingasthesystemevolves).Carefulmonitoringofqueriescanrevealunexpectedproblems;forexample,theoptimizermaynotbeusingsomeindexesasintendedtoproducegoodplans.Continueddatabasetuningisimportanttogetthebestpossibleperformance.TUNINGTHECONCEPTUALSCHEMAInthecourseofdatabasedesign,wemayrealizethatourcurrentchoiceofrelationschemasdoesnotenableusmeetourperformanceobjectivesforthegivenworkloadwithany(feasible)setofphysicaldesignchoices.Ifso,wemayhavetoredesignourconceptualschema(andre-examinephysicaldesigndecisionsthatareaffectedbythechangesthatwemake).Wemayrealizethataredesignisnecessaryduringtheinitialdesignprocessorlater,afterthesystemhasbeeninuseforawhile.Onceadatabasehasbeendesignedandpopulatedwithdata,changingtheconceptualschemarequiresasignificanteffortintermsofmappingthecontentsofrelationsthatareaffected.Nonetheless,itmaysometimesbenecessarytorevisetheconceptualschemainlightofexperiencewiththesystem.Wenowconsidertheissuesinvolvedinconceptualschema(re)designfromthepointofviewofperformance.Severaloptionsmustbeconsideredwhiletuningtheconceptualschema:Wemaydecidetosettlefora3NFdesigninsteadofaBCNFdesign.Iftherearetwowaystodecomposeagivenschemainto3NForBCNF,ourchoiceshouldbeguidedbytheworkload.SometimeswemightdecidetofurtherdecomposearelationthatisalreadyinBCNF.Inothersituationswemightdenormalize.Thatis,wemightchoosetoreplaceacollectionofrelationsobtainedbyadecompositionfromalargerrelationwiththeoriginal(larger)relation,eventhoughitsuffersfromsomeredundancyproblems.Alternatively,wemightchoosetoaddsomefieldstocertainrelationstospeedupsomeimportantqueries,evenifthisleadstoaredundantstorageofsomeinformation(andconsequently,aschemathatisinneither3NFnorBCNF).Thisdiscussionofnormalizationhasconcentratedonthetechniqueofdecomposition,whichamountstoverticalpartitioningofarelation.Anothertechniquetoconsiderishorizontalpartitioningofarelation,whichwouldleadtoourhavingtworelationswithidenticalschemas.Notethatwearenottalkingaboutphysicallypartitioningthecuplesofasinglerelation;rather,wewanttocreatetwodistinctrelations(possiblywithdifferentconstraintsandindexesoneach).Incidentally,whenweredesigntheconceptualschema,especiallyifwearetuninganexistingdatabaseschema,itisworthconsideringwhetherweshouldcreateviewstomaskthesechangesfromusersforwhomtheoriginalschemaismorenatural.TUNINGQUERIESANDVIEWSIfwenoticethataqueryisrunningmuchslowerthanweexpected,wehavetoexaminethequerycarefullytoendtheproblem.Somerewritingofthequery,perhapsinconjunctionwithsomeindextuning,canoften?xtheproblem.Similartuningmaybecalledforifqueriesonsomeviewrunslowerthanexpected.Whentuningaquery,thefirstthingtoverifyisthatthesystemisusingtheplanthatyouexpectittouse.Itmaybethatthesystemisnotfindingthebestplanforavarietyofreasons.Somecommonsituationsthatarenothandledefficientlybymanyoptimizersfollow:Aselectionconditioninvolvingnullvalues.Selectionconditionsinvolvingarithmeticorstringexpressionsorconditionsusingtheorconnective.Forexample,ifwehaveaconditionE.age=2*D.ageintheWHEREclause,theoptimizermaycorrectlyutilizeanavailableindexonE.agebutfailtoutilizeanavailableindexonD.age.ReplacingtheconditionbyE.age/2=D.agewouldreversethesituation.Inabilitytorecognizeasophisticatedplansuchasanindex-onlyscanforanaggregationqueryinvolvingaGROUPBYclause.Iftheoptimizerisnotsmartenoughtoandthebestplan(usingaccessmethodsandevaluationstrategiessupportedbytheDBMS),somesystemsallowuserstoguidethechoiceofaplanbyprovidinghintstotheoptimizer;forexample,usersmightbeabletoforcetheuseofaparticularindexorchoosethejoinorderandjoinmethod.AuserwhowishestoguideoptimizationinthismannershouldhaveathoroughunderstandingofbothoptimizationandthecapabilitiesofthegivenDBMS.(8)OTHERTOPICSMOBILEDATABASESTheavailabilityofportablecomputersandwirelesscommunicationshascreatedanewbreedofnomadicdatabaseusers.Atoneleveltheseusersaresimplyaccessingadatabasethroughanetwork,whichissimilartodistributedDBMSs.Atanotherlevelthenetworkaswellasdataandusercharacteristicsnowhaveseveralnovelproperties,whichaffectbasicassumptionsinmanycomponentsofaDBMS,includingthequeryengine,transactionmanager,andrecoverymanager.UsersareconnectedthroughawirelesslinkwhosebandwidthistentimeslessthanEthernetand100timeslessthanATMnetworks.CommunicationcostsarethereforesignificantlyhigherinproportiontoI/OandCPUcosts.Userslocationsareconstantlychanging,andmobilecomputershavealimitedbatterylife.Therefore,thetruecommunicationcostsisconnectiontimeandbatteryusageinadditiontobytestransferred,andchangeconstantlydependingonlocation.Dataisfrequentlyreplicatedtominimizethecostofaccessingitfromdifferentlocations.Asausermovesaround,datacouldbeaccessedfrommultipledatabaseserverswithinasingletransaction.Thelikelihoodoflosingconnectionsisalsomuchgreaterthaninatraditionalnetwork.Centralizedtransactionmanagementmaythereforebeimpractical,especiallyifsomedataisresidentatthemobilecomputers.WemayinfacthavetogiveuponACIDtransactionsanddevelopalternativenotionsofconsistencyforuserprograms.MAINMEMORYDATABASESThepriceofmainmemoryisnowlowenoughthatwecanbuyenoughmainmemorytoholdtheentiredatabaseformanyapplications;with64-bitaddressing,modernCPUsalsohaveverylargeaddressspaces.Somecommercialsystemsnowhaveseveralgigabytesofmainmemory.ThisshiftpromptsareexaminationofsomebasicDBMSdesigndecisions,sincediskaccessesnolongerdominateprocessingtimeforamemory-residentdatabase:Mainmemorydoesnotsurvivesystemcrashes,andsowestillhavetoimplementloggingandrecoverytoensuretransactionatomicityanddurability.Logrecordsmustbewrittentostablestorageatcommittime,andthisprocesscouldbecomeabottleneck.Tominimizethisproblem,ratherthancommiteachtransactionasitcompletes,wecancollectcompletedtransactionsandcommittheminbatches;thisiscalledgroupcommit.Recoveryalgorithmscanalsobeoptimizedsincepagesrarelyhavetobewrittenouttomakeroomforotherpages.Theimplementationofin-memoryoperationshastobeoptimizedcarefullysincediskaccessesarenolongerthelimitingfactorforperformance.Anewcriterionmustbeconsideredwhileoptimizingqueries,namelytheamountofspacerequiredtoexecuteaplan.Itisimportanttominimizethespaceoverheadbecauseexceedingavailablephysicalmemorywouldleadtoswappingpagestodisk(throughtheoperatingsystemsvirtualmemorymechanisms),greatlyslowingdownexecution.Page-orienteddatastructuresbecomelessimportant(sincepagesarenolongertheunitofdataretrieval),andclusteringisnotimportant(sincethecostofaccessinganyregionofmainmemoryisuniform).附录B外文译文（一）从历史的角度回顾从数据库的早期开始，存储和操纵数据就一直是主要的应用焦点。第一个通用的DBMS是由CharlesBechman于20世纪60年代早期在通用电器公司设计的，称为集成数据存储(IntegratedDataStore).它奠定了网状数据模型的基础。网状数据模型由数据系统语言协会(CODASYL)标准化，并在整个20世纪60年代对数据库系统产生了巨大的影响。由于Bachman在数据库领域的贡献，他成为第一个ACM图灵奖（相当于计算机科学界的诺贝尔奖）的获得者，并于1973年接受了这一奖励。20世纪60年代末期，IBM成功开发了信息管理系统(IMS)DBMS。直至今天，它还在许多系统中使用。IMS奠定了另一个数据表达框架层次数据模型的基础。同时，美国航空公司和IBM联合开发出用于飞机订票的SABRE系统，它允许多个用户通过计算机网络存取相同数据。有趣的是，今天SABRE系统被用于支持广为流行的基于Web的旅游服务，如Travelocity。1970年，EdgarCodd在IBM的SanJose研究实验室推出了一种新的，称为关系数据模型的数据表达框架。这后来被证明是数据库系统开发中的分水岭：它推进了几个基于关系模型的数据库管理系统的快速开发，并取得大量的理论成果，从而为数据库领域奠定了坚实的基础。Coff因为其杰出的工作而获得了1981年图灵奖。数据库系统作为学术学科已经成熟了，而且关系型DBMS的普及改变了商业应用前景。其益处被广泛认同，使用DBMS来管理公司数据变得很普遍。在20世纪80年代，关系模型巩固了它作为主导DBMS模式的地位，而数据库系统继续被广泛使用。作为IBM的SystemR项目的一部分而开发的关系数据库SQL查询语言，现在成为了标准查询语言。SQL于20世纪80年代末期得到标准化，目前的标准SQL:1999被美国国家标准协会（ANSI）和国际标准组织（ISO）接受。并发编程使用最广的形式就是数据库程序（称为事务）的并发执行。用户编写程序时不用考虑其他程序的运行，并发执行操作由DBMS管理。JamesGray因他对DBMS事务处理领域的贡献而获得了1999图灵奖。在20世纪80年代末期和90年代，数据库系统在很多方面得到发掌。相当多的研究侧重于功能强大的查询语言和更丰富的数据模型，其重点也放在了支持对企业各部分数据的复杂分析上。很多数据库提供商（如IBM的DB2,Oracle8,InformixUDS）樱井扩展了它们的系统，使之具有存储诸如图像，文本等新数据类型的能力，以及回答更复杂查询的能力。大量的厂商已经为创建数据仓库，继承多个数据库的数据以及实现专业化分析而开发了专用系统。一个有趣的现象是随着一些企业资源规划（ERP）和管理自愿规划（MRP）软件包的出现，他们在DBMS之上增加了一层面向应用的特征。广泛使用的软件包有Baan,Oracle,PeopleSoft,SAP和Siebel等系统，它们先确定大多数组织机构所遇到的共同任务（例如，库存管理，人力资源规划，财务分析等），并提供一个通用的应用层以完成这些任务。数据存储在关系型DBMS中，可以为不同公司分别定制应用层。与从头开始创建应用层的开销相比，这样可以降低公司的总体开销。也许，在DBMS的发展中，最重要的事是DBMS已经进入了因特网时代。第一代Web站点是把数据存储在操作系统的文件中，而现在，使用DBMS存储数据并通过Web浏览器浏览数据已变得越来越普遍。通过Web可存取的表单界面来产生查询请求，并使用诸如HTML的标记语言将查询结果格式化，从而便于在浏览器中显示。所有数据库提供商都在增加它们的DBMS功能，使之更适于在因特网上部署。随着越来越多在线数据的产生，并且通过计算机网络越来越容易获得，数据库也变得更加重要了。今天，众多领域的发展需求，例如，多媒体数据库，互动视频，流数据，数字图书馆等精彩视频节目，人类基因图和NASA的地球观测系统等科学项目，以及公司对巩固它们的决策支持处理和有用信息挖掘的渴望，正推动着数据库领域的发展。在商业上，数据库管理系统代表着最大和最具活力的市场之一。所以，有关数据库系统的研究回报丰厚！（二）物理数据库设计简介与数据库设计的其他方面一样，我们要根据数据的性质和用途来进行物理数据库设计。特别是，我们必须了解数据库所必须支持的典型的工作负载，工作负载是查询和更新的混合体。用户有一些特定的要求，如，某些查询或更新的执行速度应该有多快，或者每秒钟必须处理多少个事务等。在物理数据库设计过程中，工作负载的描述和用户的需求是作出许多决策的基础。为了获得一个好的物理数据库设计，我们还要调整系统的性能以满足用户的需求。设计者需要明白DBMS工作的细节，特别是DBMS所支持的索引和查询处理技术。如果数据库允许多个用户并发访问，或者是分布式数据库，那么这是设计任务就变得更复杂了，还需要考虑DBMS的其他特点。（三）数据库负载一个好的数据库设计的关键是对所希望的负载有准确的描述。一个工作负载的描述包括以下几个部分：1.一个查询及其出现的频率的列表，一个查询的频率指该查询在所有的查询和更新中所占的比例。2.更新及其出现的频率列表。3.每一种查询和更新类型所对应的性能目标。对于在工作负载中的每个查询，我们必须确定：需要访问哪些关系。需要保留那些属性（在SELECT子句中）。在那些属性上有选择或连接条件（在WHERE子句中），以及这些条件具有多大的选择性。类似地，对工作负载中每个更新，我们必须确定：在哪些属性上有选择或连接条件（在WHERE语句中），以及有多大的选择性。更新的类型（INSERT,DELETE,UPDATE）以及所要更新的关系。对于UPDATE命令，要更新哪些字段。典型的查询和更新都带有参数，例如，借款或存款操作都涉及某个特定的帐号。这些参数的值决定了选择和连接条件的选择性。更新中包括一个查询部分，用来找到目标元组。这个部分可以得益于一个好的物理设计和索引。另一方面，更新操作一般还要做一些额外的工作，以维护所修改的属性上的索引。这样，尽管查询总可以从索引受益，但是索引也可能使一个给定的更新加快或变慢。在生成索引时，设计者应该在头脑中进行一下权衡。（四）数据库调整的必要性准确地讲，在系统设计的初始阶段，我们很难得到工作负载的详细信息。所以在系统设计完以后，对数据库的调整就变得很重要，我们必须按照实际的使用模式来对初始的设计进行求精，以便获得好的性能。对于如何区别数据库设计和数据库调整，人们有不同的看法。一种看法认为，一旦初始模式、索引和聚簇决策已经确定，那么设计过程也就结束了。接下去对概念模式或索引的任何改变，都被认为是对数据库进行调整的活动。另一种看法是，对于概念模式的进一步求精（和受这些改进影响的物理设计决策）也应该是物理设计过程的一部分。如何区分设计和调整并不是很重要的（五）数据库调整简介当数据库初始设计完成后，数据库的实际使用提供了一些有用的详细信息，它们可以用来对初始设计进行进一步求精。先前对工作负载的很多假设都可以用观察到的模式来代替；一般来讲，一些初始的关于工作负载的说明将得到验证，其中有一些可能是错误的。关于数据大小的初始猜测可以用实际的数据库的统计数字来代替（尽管这个信息会随着系统的不断进化而变化）。对于查询的仔细监测可龕发现一些预测不到的问题，例如，优化器可能不使用某些索引，尽管这些索引可以产生好的计划。为了获得可能的最好的性能，对数据库进行连续的调整是很重要的。（六）调整概念模式在数据库设计期间，我们也许会意识到，在给定工作负载和任何一组可行的物理设计选择的情况下，当前选择的关系模式并不能满足性能目标。如果是这样，我们也许必须重新设计概念模式（而且还要重新检查那些受到影响的物理设计决策）。在系统已经运行了一段时间后，我们也许会认识到在初始设计期间或之后重新设计的必要性。一旦数据库设计完成并且已经被装载数据了，如果要改变概念模式，就需要做出很大的努力