餐廳管理系統數據庫外文翻譯文獻餐廳管理系統數據庫外文翻譯文獻(文檔含中英文對照即英文原文和中文翻譯)譯文：數據庫1.1數據庫的概念自20世紀60年代，數據庫的概念演變以來，用來緩解在設計、建設日益困難的信息系統（通常是多個并發用戶，并用大量不同的數據）。它已經連同數據庫管理系統一起演變，促使數據庫得到有效的管理。盡管數據庫和DBMS所表達的定義實體不同，但是他們是不可分割的：一個數據庫的性能決定于它支撐的DBMS，反之亦然。牛津英語詞典引用了1962年的技術報告的“數據基礎”術語。隨著處理器領域的科技進步，計算機內存、計算機存儲和計算機網絡的尺寸、功能以及數據庫和各自的DBMS性能有了數量級的增長。幾十年來，它已經不可能是一個復雜的信息系統可以有效地建立不由DBMS支持的一個適當的數據庫。數據庫的利用現在蔓延到這樣廣泛的程度：幾乎所有的技術和產品依靠數據庫和DBMS，促使自身的發展和商業化，甚至可能已經嵌入它。同時，組織和公司，從小型到大型，在很大程度上依賴于他們的工作數據庫。DBMS中存在不普遍被接受的定義。然而，作為DBMS，一個系統需要提供大量的功能。因此，它支持的數據收集需要滿足各自的可用性需求（大致按以下要求定義），有資格作為一個數據庫。因此，一個數據庫和它支持的DBMS通過一組一般要求所列被定義的。幾乎所有存在的成熟的DBMS產品在很大程度上滿足這些需求，雖然不夠成熟或者滿足他們，哪怕收斂到滿足他們。1.2數據庫和DBMS的演變引進數據庫的術語與直接訪問存儲的可能性（磁盤和鼓）正好都是從20世紀60年代以前開始。這個術語體現了與過去基于磁帶的系統相比，允許共享交互使用，而不是每天的批處理。在最早的數據庫系統中，效率也許是首要關注的問題，但是它已經意識到，有別的更重要的目標。一個關鍵的目標是使數據獨立于應用程序的邏輯，以至于同樣的數據能夠提供不同的應用。第一代的數據庫系統是導航的，典型的應用訪問數據隨著指針從一個記錄到另一個。兩個主要的數據模型在這個時間是層次模型，通過IBM的IMS系統的縮影，和CODASYL模型（網絡模型），實現一系列的產品，比如IDMS。關系模型首先由埃德加樓科德在20世紀70年代首次提出，離開這個傳統，堅持應用程序應搜索數據的內容，而不是通過鏈接。讓數據庫的內容不通過不間斷的重寫應用而進化，這被認為是有必要的。關系系統在處理資源上放在了很高的需求上，直到20世紀80年代計算機硬件變得足夠強大以允許他們能被廣泛部署。在20世紀90年代早期，然而，關系系統對于所有大規模的數據處理應用占優勢，并且他們今天（2012）仍然占主導地位，除了在有利可圖的領域。占主導地位的數據庫語言對于關系模型是SQL的標準，已經影響數據庫語言，甚至在其它領域。由于關系模型強調搜索而不是導航。它不能使不同實體的指針明確關系，但代表它們而使用主鍵和外鍵。雖然這對于查詢語言是一個好的基礎，它不適合作為一個建模語言。因此對于不同的模型，實體關系模型出現不久（1976），對于數據庫設計得到了普及。自20世紀70年代以來，數據庫技術跟日益增長的資源保持同步，成為可利用的計算機平臺：尤其是容量和速度（降低價格）快速提高的磁盤存儲器，以及主存的容量增長。這使得更大的數據庫和更高的吞吐量被達到。關系模型的剛度，它所有的數據保持在行和列的一個固定結構里，當提供更富有或者更多元的信息系統已經越來越被看做是一個限制：比如，文獻數據庫、工程數據庫、多媒體數據庫、或者應用在分子科學的數據庫。各式各樣的嘗試已經被用來解決這個問題，他們中的許多在后關系或者NoSQL的旗幟下聚集。值得注意的是兩個對象數據庫和XML數據庫的發展。關系數據庫的廠商為了支持更廣泛的數據類型，通過擴大他們自己產品的容量，已經擊退了這些新的模式競爭。1.3一般用途的DBMS數千人多年的努力發展，一些通用的數據庫，像Oracle、微軟的SQLServer和IBMDB2，已經經歷了三十年或者更長時間的升級。通用的數據庫管理系統旨在盡可能的滿足足夠多的申請，通常使他們比專用數據庫更復雜。然而，事實上，他們可以被使用為“現成的”，此外他們在許多應用程序和實例中分期償還成本，使他們成為有吸引力的替代品（并非一次性的發展）在他們隨時滿足應用的需求時。盡管在許多情況下有吸引力，一個通用的數據庫管理系統并非總是一個最佳的解決方案：當某些應用在操作領域是普遍的，每個擁有許多用戶，一個通用的數據庫管理系統或許能夠引進不必要的經費和開銷過大的“足跡”（太大量的不必要、未使用的軟件代碼）。這些應用程序通常為致力于發展。典型的例子是電子郵件系統，但他們需要具備一定的DBMS性能：電子郵件系統是建立在優化電子郵件信息處理和管理的方法上，而不需要一個通用的數據庫管理系統功能的重要部分。1.4數據庫的機器和設備在20世紀70年代和80年代試圖集成硬件和軟件建立數據庫系統。它的基本理念是：這種結合將會在較低的成本花費上提供更高的性能。例子是IBM/38系統，最早發行的Teradata，布里頓李有限公司的數據庫機器。數據庫管理的另一種硬件支持的方法是ICL的內容尋址的文件存儲加速器，一個可編程的搜索功能的硬件磁盤控制器。長期的這些努力通常是不會成功的，因為專門的數據庫機器不能夠與隨著科技的飛速發展而快速進步的計算機保持同步。因此，現如今大部分的數據庫系統是軟件系統運行在通用的硬件上，使用通用的計算機存儲。然而這種觀念仍然追求一些公司Netezza和Oracle的某些應用。1.5數據庫的研究數據庫的研究一直處在一個活躍的和多樣化的領域里，和許多專業，進行了從早期20世紀60年代以來的處理數據庫概念系統。它與數據庫技術和DBMS產品有強大的聯結。數據庫的研究已經發展到企業的研究和開發組的研究（比如：尤其是IBM的研究，促使技術和理念，幾乎任何數據管理系統存在的今天），研究機構和學術界。研究通過理論和原型已經完成。研究和數據庫相關產品的研發的合作一直以來都是數據庫領域非常有成效的，許多相關的關鍵概念和技術由此產生。值得注意的是，關系和實體關系模型，原子事務的概念和相關的并發控制技術，查詢語言和查詢優化方法模型，磁盤冗余陣列，以及更多的。研究對于數據庫幾乎所有的方面都已經提供了深刻的洞察力，盡管不是一直都是務實的，有效的（并不能并且不總是：研究是探索性的，并不總是導致接受或者有用的想法）。最終，市場力量和實際需要確定問題解決方案的選擇和相關技術，甚至包括那些提出來的研究。然而，有時候，不是最好的、最有優雅的解決方案獲勝（例如，SQL）。數據庫管理系統和相應的數據庫追溯它們的歷史，在很大程度上，有了這種研究的結果，而實際產品的需求和挑戰引發了數據庫的方向和分區。數據庫的研究領域有一些值得關注的專門的學術刊物（例如，ACM處理交易數據庫系統工具，數據與知識工程DKE，以及更多）和年度會議（例如，ACM，ACM莢，VLDB，IEEEICDE以及更多），以及一些活躍的和相當混雜的（主體明智）全世界的研究團體。1.6數據庫體系結構數據庫體系結構（為了區別于DBMS體系結構；見下文）或許被認為，在某種程度上，作為數據模型的擴展。它是用來方便地回答不同的最終用戶從同一個數據庫的需求，以及其他利益。例如，一個公司的財務部需要所有員工的付款的詳細資料作為公司的一部分費用，而不是關于員工其他的許多詳細資料，那是人力資源部門的利益。因此，不同的部門需要公司不同的數據庫觀點，既包括員工薪酬，可能在不同水平的細節資料（以不同的視覺形式體現）。為了滿足這種需求，有效的數據庫系統需要三級組成部分：外部和內部，概念。明確地區分這三點是關系數據庫模型的實現，以至于控制第21個世紀數據庫的一個主要的特征。外部層定義每一個終端用戶類型了解數據庫組織的各自相關數據，即，終端用戶不同的需求觀點。一個數據庫在外部層能夠有任何數量的不同觀點。概念層結合各種外部觀點納入一個有機整體，全局觀點。它提供了所有的外部觀點的共同點。它包括所有終端用戶的通用數據，即，所有的數據從任何一個視圖可以導出/計算。它被證明是最簡單的可能的方式提供這些通用的數據，包括數據庫的背骨。出于對各種數據庫終端用戶的范圍，服務型數據庫應用程序技術開發人員和數據庫管理人員，建立數據庫定義。內部層（或物理層）是作為數據庫一個事實的一部分貫徹在數據庫管理系統里（見下面的實現部分）。它關注的是成本，性能，可擴展性和其他的業務事項。它處理概念層的存儲布局，像指標一樣提供支持的存儲結構，用來提高性能，偶爾存儲個人看法的數據（物化視圖），從通用的數據來計算，如果這樣的冗余性能無過失的存在。它平衡所有的外部視圖的性能要求，可能是相互沖突的，通過所有的最終用途，根據數據庫的目標和優先事項，為優化整個數據庫的使用。所有這三層是通過不斷變化的需求的經常參與數據庫設計的數據庫管理員來維護和更新。上述三層數據庫結構還涉及出于數據獨立性的概念，已經被長時間描述為所需的數據庫屬性和一個重要的初始驅動的關系模型。在以上的結構語境里它意味著在一定程度上的改變不影響定義和高層次的接口軟件開發，并且被自動納入在更高的水平。例如，在內部水平的變化不影響編寫應用程序使用概念層次的接口，這些節省了大量的工作，否則就需要改變?？傊?，這個概念是在內部與外部之間的一級間接尋址。一方面它提供一個數據庫的共同看法，獨立在不同的外部視圖結構，另一方面它是由簡單的被存儲和管理的詳細說明的數據（內部水平）。原則上每個水平，甚至每一個外部視圖，能夠通過不同的數據模型被展現。在實踐中，通常一個特定的數據庫無論是外部的和概念層，使用相同的數據模型（例如，關系模型）。內部層，隱藏在數據庫管理系統并且取決于它的實現（看如下的實現部分），需要不同的詳細的水平，使用它自己的數據結構類型，從被暴露于數據庫管理系統用戶外部和概念層次結構的性質通常是不同的（例如，如上的數據模型）：當外部層次和概念都集中在服務用戶的數據庫管理系統，內部層次的關注是有效的實施細則。來源于：TheWikipediaRevolution[M].北京：北京科文圖書業信息技術有限公司，2009.3.原文：DatabaseAuthor:AndrewLihDatabaseconceptThedatabaseconcepthasevolvedsincethe1960stoeaseincreasingdifficultiesindesigning,building,andmaintainingcomplexinformationsystems(typicallywithmanyconcurrentend-users,andwithalargeamountofdiversedata).Ithasevolvedtogetherwithdatabasemanagementsystemswhichenabletheeffectivehandlingofdatabases.ThoughthetermsdatabaseandDBMSdefinedifferententities,theyareinseparable:adatabase'spropertiesaredeterminedbyitssupportingDBMSandvice-versa.TheOxfordEnglishdictionarycitesa1962technicalreportasthefirsttousetheterm"data-base."Withtheprogressintechnologyintheareasofprocessors,computermemory,computerstorageandcomputernetworks,thesizes,capabilities,andperformanceofdatabasesandtheirrespectiveDBMSshavegrowninordersofmagnitudes.FordecadesithasbeenunlikelythatacomplexinformationsystemcanbebuilteffectivelywithoutaproperdatabasesupportedbyaDBMS.TheutilizationofdatabasesisnowspreadtosuchawidedegreethatvirtuallyeverytechnologyandproductreliesondatabasesandDBMSsforitsdevelopmentandcommercialization,orevenmayhavesuchembeddedinit.Also,organizationsandcompanies,fromsmalltolarge,heavilydependondatabasesfortheiroperations.NowidelyacceptedexactdefinitionexistsforDBMS.However,asystemneedstoprovideconsiderablefunctionalitytoqualifyasaDBMS.Accordinglyitssupporteddatacollectionneedstomeetrespectiveusabilityrequirements(broadlydefinedbytherequirementsbelow)toqualifyasadatabase.Thus,adatabaseanditssupportingDBMSaredefinedherebyasetofgeneralrequirementslistedbelow.VirtuallyallexistingmatureDBMSproductsmeettheserequirementstoagreatextent,whilelessmatureeithermeetthemorconvergetomeetthem.EvolutionofdatabaseandDBMStechnologyADBMShasevolvedintoacomplexsoftwaresystemanditsdevelopmenttypicallyrequirestheevolutionofdatabaseandDBMStechnologyTheintroductionofthetermdatabasecoincidedwiththeavailabilityofdirect-accessstorage(disksanddrums)fromthemid-1960sonwards.Thetermrepresentedacontrastwiththetape-basedsystemsofthepast,allowingsharedinteractiveuseratherthandailybatchprocessing.Intheearliestdatabasesystems,efficiencywasperhapstheprimaryconcern,butitwasalreadyrecognizedthattherewereotherimportantobjectives.Oneofthekeyaimswastomakethedataindependentofthelogicofapplicationprograms,sothatthesamedatacouldbemadeavailabletodifferentapplications.Thefirstgenerationofdatabasesystemswerenavigational,applicationstypicallyaccesseddatabyfollowingpointersfromonerecordtoanother.Thetwomaindatamodelsatthistimewerethehierarchicalmodel,epitomizedbyIBM'sIMSsystem,andtheCodasylmodel(Networkmodel),implementedinanumberofproductssuchasIDMS.TheRelationalmodel,firstproposedin1970byEdgarF.Codd,departedfromthistraditionbyinsistingthatapplicationsshouldsearchfordatabycontent,ratherthanbyfollowinglinks.Thiswasconsiderednecessarytoallowthecontentofthedatabasetoevolvewithoutconstantrewritingofapplications.Relationalsystemsplacedheavydemandsonprocessingresources,anditwasnotuntilthemid1980sthatcomputinghardwarebecamepowerfulenoughtoallowthemtobewidelydeployed.Bytheearly1990s,however,relationalsystemsweredominantforalllarge-scaledataprocessingapplications,andtheyremaindominanttoday(2012)exceptinnicheareas.ThedominantdatabaselanguageisthestandardSQLfortheRelationalmodel,whichhasinfluenceddatabaselanguagesalsoforotherdatamodels.Becausetherelationalmodelemphasizessearchratherthannavigation,itdoesnotmakerelationshipsbetweendifferententitiesexplicitintheformofpointers,butrepresentsthemratherusingprimarykeysandforeignkeys.Whilethisisagoodbasisforaquerylanguage,itislesswellsuitedasamodelinglanguage.Forthisreasonadifferentmodel,theEntity-relationshipmodelwhichemergedshortlylater(1976),gainedpopularityfordatabasedesign.Intheperiodsincethe1970sdatabasetechnologyhaskeptpacewiththeincreasingresourcesbecomingavailablefromthecomputingplatform:notablytherapidincreaseinthecapacityandspeed(andreductioninprice)ofdiskstorage,andtheincreasingcapacityofmainmemory.Thishasenabledeverlargerdatabasesandhigherthroughputstobeachieved.Therigidityoftherelationalmodel,inwhichalldataisheldintableswithafixedstructureofrowsandcolumns,hasincreasinglybeenseenasalimitationwhenhandlinginformationthatisricherormorevariedinstructurethanthetraditional'ledger-book'dataofcorporateinformationsystems:forexample,documentdatabases,engineeringdatabases,multimediadatabases,ordatabasesusedinthemolecularsciences.Variousattemptshavebeenmadetoaddressthisproblem,manyofthemgatheringunderbannerssuchaspost-relationalorNoSQL.TwodevelopmentsofnotearetheObjectdatabaseandtheXMLdatabase.Thevendorsofrelationaldatabaseshavefoughtoffcompetitionfromthesenewermodelsbyextendingthecapabilitiesoftheirownproductstosupportawidervarietyofdatatypes.General-purposeDBMSThousandsofperson-yearsofdevelopmenteffort.Somegeneral-purposeDBMSs,likeOracle,MicrosoftSQLServer,andIBMDB2,havebeenundergoingupgradesforthirtyyearsormore.General-purposeDBMSsaimtosatisfyasmanyapplicationsaspossible,whichtypicallymakesthemevenmorecomplexthanspecial-purposedatabases.However,thefactthattheycanbeused"offtheshelf",aswellastheiramortizedcostovermanyapplicationsandinstances,makesthemanattractivealternative(Vsone-timedevelopment)whenevertheymeetanapplication'srequirements.Thoughattractiveinmanycases,ageneral-purposeDBMSisnotalwaystheoptimalsolution:Whencertainapplicationsarepervasivewithmanyoperatinginstances,eachwithmanyusers,ageneral-purposeDBMSmayintroduceunnecessaryoverheadandtoolarge"footprint"(toolargeamountofunnecessary,unutilizedsoftwarecode).Suchapplicationsusuallyjustifydedicateddevelopment.Typicalexamplesareemailsystems,thoughtheyneedtopossesscertainDBMSproperties:emailsystemsarebuiltinawaythatoptimizesemailmessageshandlingandmanaging,anddonotneedsignificantportionsofageneral-purposeDBMSfunctionality.DatabasemachinesandappliancesInthe1970sand1980sattemptsweremadetobuilddatabasesystemswithintegratedhardwareandsoftware.Theunderlyingphilosophywasthatsuchintegrationwouldprovidehigherperformanceatlowercost.ExampleswereIBMSystem/38,theearlyofferingofTeradata,andtheBrittonLee,Inc.databasemachine.AnotherapproachtohardwaresupportfordatabasemanagementwasICL'sCAFSaccelerator,ahardwarediskcontrollerwithprogrammablesearchcapabilities.Inthelongtermtheseeffortsweregenerallyunsuccessfulbecausespecializeddatabasemachinescouldnotkeeppacewiththerapiddevelopmentandprogressofgeneral-purposecomputers.Thusmostdatabasesystemsnowadaysaresoftwaresystemsrunningongeneral-purposehardware,usinggeneral-purposecomputerdatastorage.HoweverthisideaisstillpursuedforcertainapplicationsbysomecompanieslikeNetezzaandOracle.DatabaseresearchDatabaseresearchhasbeenanactiveanddiversearea,withmanyspecializations,carriedoutsincetheearlydaysofdealingwiththedatabaseconceptinthe1960s.IthasstrongtieswithdatabasetechnologyandDBMSproducts.Databaseresearchhastakenplaceatresearchanddevelopmentgroupsofcompanies(e.g.,notablyatIBMResearch,whocontributedtechnologiesandideasvirtuallytoanyDBMSexistingtoday),researchinstitutes,andAcademia.ResearchhasbeendoneboththroughTheoryandPrototypes.Theinteractionbetweenresearchanddatabaserelatedproductdevelopmenthasbeenveryproductivetothedatabasearea,andmanyrelatedkeyconceptsandtechnologiesemergedfromit.NotablearetheRelationalandtheEntity-relationshipmodels,theAtomictransactionconceptandrelatedConcurrencycontroltechniques,QuerylanguagesandQueryoptimizationmethods,RAID,andmore.Researchhasprovideddeepinsighttovirtuallyallaspectsofdatabases,thoughnotalwayshasbeenpragmatic,effective(andcannotandshouldnotalwaysbe:researchisexploratoryinnature,andnotalwaysleadstoacceptedorusefulideas).Ultimatelymarketforcesandrealneedsdeterminetheselectionofproblemsolutionsandrelatedtechnologies,alsoamongthoseproposedbyresearch.However,occasionally,notthebestandmostelegantsolutionwins(e.g.,SQL).AlongtheirhistoryDBMSsandrespectivedatabases,toagreatextent,havebeentheoutcomeofsuchresearch,whilerealproductrequirementsandchallengestriggereddatabaseresearchdirectionsandsub-areas.Thedatabaseresearchareahasseveralnotablededicatedacademicjournals(e.g.,ACMTransactionsonDatabaseSystems-TODS,DataandKnowledgeEngineering-DKE,andmore)andannualconferences(e.g.,ACMSIGMOD,ACMPODS,VLDB,IEEEICDE,andmore),aswellasanactiveandquiteheterogeneous(subject-wise)researchcommunityallovertheworld.DatabasearchitectureDatabasearchitecture(tobedistinguishedfromDBMSarchitecture;seebelow)maybeviewed,tosomeextent,asanextensionofDatamodeling.Itisusedtoconvenientlyanswerrequirementsofdifferentend-usersfromasamedatabase,aswellasforotherbenefits.Forexample,afinancialdepartmentofacompanyneedsthepaymentdetailsofallemployeesaspartofthecompany'sexpenses,butnotothermanydetailsaboutemployees,thataretheinterestofthehumanresourcesdepartment.Thusdifferentdepartmentsneeddifferentviewsofthecompany'sdatabase,thatbothincludetheemployees'payments,possiblyinadifferentlevelofdetail(andpresentedindifferentvisualforms).Tomeetsuchrequirementeffectivelydatabasearchitectureconsistsofthreelevels:external,conceptualandinternal.Clearlyseparatingthethreelevelswasamajorfeatureoftherelationaldatabasemodelimplementationsthatdominate21stcenturydatabases.Theexternalleveldefineshoweachend-usertypeunderstandstheorganizationofitsrespectiverelevantdatainthedatabase,i.e.,thedifferentneededend-userviews.Asingledatabasecanhaveanynumberofviewsattheexternallevel.Theconceptuallevelunifiesthevariousexternalviewsintoacoherentwhole,globalview.Itprovidesthecommon-denominatorofalltheexternalviews.Itcomprisesalltheend-userneededgenericdata,i.e.,allthedatafromwhichanyviewmaybederived/computed.Itisprovidedinthesimplestpossiblewayofsuchgenericdata,andcomprisestheback-boneofthedatabase.Itisoutofthescopeofthevariousdatabaseend-users,andservesdatabaseapplicationdevelopersanddefinedbydatabaseadministratorsthatbuildthedatabase.TheInternallevel(orPhysicallevel)isasamatteroffactpartofthedatabaseimplementationinsideaDBMS(seeImplementationsectionbelow).Itisconcernedwithcost,performance,scalabilityandotheroperationalmatters.Itdealswithstoragelayoutoftheconceptuallevel,providessupportingstorage-structureslikeindexes,toenhanceperformance,andoccasionallystoresdataofindividualviews(materializedviews),computedfromgenericdata,ifperformancejustificationexistsforsuchredundancy.Itbalancesalltheexternalviews'performancerequirements,possiblyconflicting,inattempttooptimizetheoveralldatabaseusagebyallitsend-usesaccordingtothedatabasegoalsandpriorities.Allthethreelevelsaremaintainedandupdatedaccordingtochangingneedsbydatabaseadministrators