餐廳管理系統(tǒng)數(shù)據(jù)庫外文翻譯文獻

餐廳管理系統(tǒng)數(shù)據(jù)庫外文翻譯文獻餐廳管理系統(tǒng)數(shù)據(jù)庫外文翻譯文獻(文檔含中英文對照即英文原文和中文翻譯)譯文：數(shù)據(jù)庫1.1數(shù)據(jù)庫的概念自20世紀60年代，數(shù)據(jù)庫的概念演變以來，用來緩解在設計、建設日益困難的信息系統(tǒng)（通常是多個并發(fā)用戶，并用大量不同的數(shù)據(jù)）。它已經連同數(shù)據(jù)庫管理系統(tǒng)一起演變，促使數(shù)據(jù)庫得到有效的管理。盡管數(shù)據(jù)庫和DBMS所表達的定義實體不同，但是他們是不可分割的：一個數(shù)據(jù)庫的性能決定于它支撐的DBMS，反之亦然。牛津英語詞典引用了1962年的技術報告的“數(shù)據(jù)基礎”術語。隨著處理器領域的科技進步，計算機內存、計算機存儲和計算機網絡的尺寸、功能以及數(shù)據(jù)庫和各自的DBMS性能有了數(shù)量級的增長。幾十年來，它已經不可能是一個復雜的信息系統(tǒng)可以有效地建立不由DBMS支持的一個適當?shù)臄?shù)據(jù)庫。數(shù)據(jù)庫的利用現(xiàn)在蔓延到這樣廣泛的程度：幾乎所有的技術和產品依靠數(shù)據(jù)庫和DBMS，促使自身的發(fā)展和商業(yè)化，甚至可能已經嵌入它。同時，組織和公司，從小型到大型，在很大程度上依賴于他們的工作數(shù)據(jù)庫。DBMS中存在不普遍被接受的定義。然而，作為DBMS，一個系統(tǒng)需要提供大量的功能。因此，它支持的數(shù)據(jù)收集需要滿足各自的可用性需求（大致按以下要求定義），有資格作為一個數(shù)據(jù)庫。因此，一個數(shù)據(jù)庫和它支持的DBMS通過一組一般要求所列被定義的。幾乎所有存在的成熟的DBMS產品在很大程度上滿足這些需求，雖然不夠成熟或者滿足他們，哪怕收斂到滿足他們。1.2數(shù)據(jù)庫和DBMS的演變引進數(shù)據(jù)庫的術語與直接訪問存儲的可能性（磁盤和鼓）正好都是從20世紀60年代以前開始。這個術語體現(xiàn)了與過去基于磁帶的系統(tǒng)相比，允許共享交互使用，而不是每天的批處理。在最早的數(shù)據(jù)庫系統(tǒng)中，效率也許是首要關注的問題，但是它已經意識到，有別的更重要的目標。一個關鍵的目標是使數(shù)據(jù)獨立于應用程序的邏輯，以至于同樣的數(shù)據(jù)能夠提供不同的應用。第一代的數(shù)據(jù)庫系統(tǒng)是導航的，典型的應用訪問數(shù)據(jù)隨著指針從一個記錄到另一個。兩個主要的數(shù)據(jù)模型在這個時間是層次模型，通過IBM的IMS系統(tǒng)的縮影，和CODASYL模型（網絡模型），實現(xiàn)一系列的產品，比如IDMS。關系模型首先由埃德加樓科德在20世紀70年代首次提出，離開這個傳統(tǒng)，堅持應用程序應搜索數(shù)據(jù)的內容，而不是通過鏈接。讓數(shù)據(jù)庫的內容不通過不間斷的重寫應用而進化，這被認為是有必要的。關系系統(tǒng)在處理資源上放在了很高的需求上，直到20世紀80年代計算機硬件變得足夠強大以允許他們能被廣泛部署。在20世紀90年代早期，然而，關系系統(tǒng)對于所有大規(guī)模的數(shù)據(jù)處理應用占優(yōu)勢，并且他們今天（2012）仍然占主導地位，除了在有利可圖的領域。占主導地位的數(shù)據(jù)庫語言對于關系模型是SQL的標準，已經影響數(shù)據(jù)庫語言，甚至在其它領域。由于關系模型強調搜索而不是導航。它不能使不同實體的指針明確關系，但代表它們而使用主鍵和外鍵。雖然這對于查詢語言是一個好的基礎，它不適合作為一個建模語言。因此對于不同的模型，實體關系模型出現(xiàn)不久（1976），對于數(shù)據(jù)庫設計得到了普及。自20世紀70年代以來，數(shù)據(jù)庫技術跟日益增長的資源保持同步，成為可利用的計算機平臺：尤其是容量和速度（降低價格）快速提高的磁盤存儲器，以及主存的容量增長。這使得更大的數(shù)據(jù)庫和更高的吞吐量被達到。關系模型的剛度，它所有的數(shù)據(jù)保持在行和列的一個固定結構里，當提供更富有或者更多元的信息系統(tǒng)已經越來越被看做是一個限制：比如，文獻數(shù)據(jù)庫、工程數(shù)據(jù)庫、多媒體數(shù)據(jù)庫、或者應用在分子科學的數(shù)據(jù)庫。各式各樣的嘗試已經被用來解決這個問題，他們中的許多在后關系或者NoSQL的旗幟下聚集。值得注意的是兩個對象數(shù)據(jù)庫和XML數(shù)據(jù)庫的發(fā)展。關系數(shù)據(jù)庫的廠商為了支持更廣泛的數(shù)據(jù)類型，通過擴大他們自己產品的容量，已經擊退了這些新的模式競爭。1.3一般用途的DBMS數(shù)千人多年的努力發(fā)展，一些通用的數(shù)據(jù)庫，像Oracle、微軟的SQLServer和IBMDB2，已經經歷了三十年或者更長時間的升級。通用的數(shù)據(jù)庫管理系統(tǒng)旨在盡可能的滿足足夠多的申請，通常使他們比專用數(shù)據(jù)庫更復雜。然而，事實上，他們可以被使用為“現(xiàn)成的”，此外他們在許多應用程序和實例中分期償還成本，使他們成為有吸引力的替代品（并非一次性的發(fā)展）在他們隨時滿足應用的需求時。盡管在許多情況下有吸引力，一個通用的數(shù)據(jù)庫管理系統(tǒng)并非總是一個最佳的解決方案：當某些應用在操作領域是普遍的，每個擁有許多用戶，一個通用的數(shù)據(jù)庫管理系統(tǒng)或許能夠引進不必要的經費和開銷過大的“足跡”（太大量的不必要、未使用的軟件代碼）。這些應用程序通常為致力于發(fā)展。典型的例子是電子郵件系統(tǒng)，但他們需要具備一定的DBMS性能：電子郵件系統(tǒng)是建立在優(yōu)化電子郵件信息處理和管理的方法上，而不需要一個通用的數(shù)據(jù)庫管理系統(tǒng)功能的重要部分。1.4數(shù)據(jù)庫的機器和設備在20世紀70年代和80年代試圖集成硬件和軟件建立數(shù)據(jù)庫系統(tǒng)。它的基本理念是：這種結合將會在較低的成本花費上提供更高的性能。例子是IBM/38系統(tǒng)，最早發(fā)行的Teradata，布里頓李有限公司的數(shù)據(jù)庫機器。數(shù)據(jù)庫管理的另一種硬件支持的方法是ICL的內容尋址的文件存儲加速器，一個可編程的搜索功能的硬件磁盤控制器。長期的這些努力通常是不會成功的，因為專門的數(shù)據(jù)庫機器不能夠與隨著科技的飛速發(fā)展而快速進步的計算機保持同步。因此，現(xiàn)如今大部分的數(shù)據(jù)庫系統(tǒng)是軟件系統(tǒng)運行在通用的硬件上，使用通用的計算機存儲。然而這種觀念仍然追求一些公司Netezza和Oracle的某些應用。1.5數(shù)據(jù)庫的研究數(shù)據(jù)庫的研究一直處在一個活躍的和多樣化的領域里，和許多專業(yè)，進行了從早期20世紀60年代以來的處理數(shù)據(jù)庫概念系統(tǒng)。它與數(shù)據(jù)庫技術和DBMS產品有強大的聯(lián)結。數(shù)據(jù)庫的研究已經發(fā)展到企業(yè)的研究和開發(fā)組的研究（比如：尤其是IBM的研究，促使技術和理念，幾乎任何數(shù)據(jù)管理系統(tǒng)存在的今天），研究機構和學術界。研究通過理論和原型已經完成。研究和數(shù)據(jù)庫相關產品的研發(fā)的合作一直以來都是數(shù)據(jù)庫領域非常有成效的，許多相關的關鍵概念和技術由此產生。值得注意的是，關系和實體關系模型，原子事務的概念和相關的并發(fā)控制技術，查詢語言和查詢優(yōu)化方法模型，磁盤冗余陣列，以及更多的。研究對于數(shù)據(jù)庫幾乎所有的方面都已經提供了深刻的洞察力，盡管不是一直都是務實的，有效的（并不能并且不總是：研究是探索性的，并不總是導致接受或者有用的想法）。最終，市場力量和實際需要確定問題解決方案的選擇和相關技術，甚至包括那些提出來的研究。然而，有時候，不是最好的、最有優(yōu)雅的解決方案獲勝（例如，SQL）。數(shù)據(jù)庫管理系統(tǒng)和相應的數(shù)據(jù)庫追溯它們的歷史，在很大程度上，有了這種研究的結果，而實際產品的需求和挑戰(zhàn)引發(fā)了數(shù)據(jù)庫的方向和分區(qū)。數(shù)據(jù)庫的研究領域有一些值得關注的專門的學術刊物（例如，ACM處理交易數(shù)據(jù)庫系統(tǒng)工具，數(shù)據(jù)與知識工程DKE，以及更多）和年度會議（例如，ACM，ACM莢，VLDB，IEEEICDE以及更多），以及一些活躍的和相當混雜的（主體明智）全世界的研究團體。1.6數(shù)據(jù)庫體系結構數(shù)據(jù)庫體系結構（為了區(qū)別于DBMS體系結構；見下文）或許被認為，在某種程度上，作為數(shù)據(jù)模型的擴展。它是用來方便地回答不同的最終用戶從同一個數(shù)據(jù)庫的需求，以及其他利益。例如，一個公司的財務部需要所有員工的付款的詳細資料作為公司的一部分費用，而不是關于員工其他的許多詳細資料，那是人力資源部門的利益。因此，不同的部門需要公司不同的數(shù)據(jù)庫觀點，既包括員工薪酬，可能在不同水平的細節(jié)資料（以不同的視覺形式體現(xiàn)）。為了滿足這種需求，有效的數(shù)據(jù)庫系統(tǒng)需要三級組成部分：外部和內部，概念。明確地區(qū)分這三點是關系數(shù)據(jù)庫模型的實現(xiàn)，以至于控制第21個世紀數(shù)據(jù)庫的一個主要的特征。外部層定義每一個終端用戶類型了解數(shù)據(jù)庫組織的各自相關數(shù)據(jù)，即，終端用戶不同的需求觀點。一個數(shù)據(jù)庫在外部層能夠有任何數(shù)量的不同觀點。概念層結合各種外部觀點納入一個有機整體，全局觀點。它提供了所有的外部觀點的共同點。它包括所有終端用戶的通用數(shù)據(jù)，即，所有的數(shù)據(jù)從任何一個視圖可以導出/計算。它被證明是最簡單的可能的方式提供這些通用的數(shù)據(jù)，包括數(shù)據(jù)庫的背骨。出于對各種數(shù)據(jù)庫終端用戶的范圍，服務型數(shù)據(jù)庫應用程序技術開發(fā)人員和數(shù)據(jù)庫管理人員，建立數(shù)據(jù)庫定義。內部層（或物理層）是作為數(shù)據(jù)庫一個事實的一部分貫徹在數(shù)據(jù)庫管理系統(tǒng)里（見下面的實現(xiàn)部分）。它關注的是成本，性能，可擴展性和其他的業(yè)務事項。它處理概念層的存儲布局，像指標一樣提供支持的存儲結構，用來提高性能，偶爾存儲個人看法的數(shù)據(jù)（物化視圖），從通用的數(shù)據(jù)來計算，如果這樣的冗余性能無過失的存在。它平衡所有的外部視圖的性能要求，可能是相互沖突的，通過所有的最終用途，根據(jù)數(shù)據(jù)庫的目標和優(yōu)先事項，為優(yōu)化整個數(shù)據(jù)庫的使用。所有這三層是通過不斷變化的需求的經常參與數(shù)據(jù)庫設計的數(shù)據(jù)庫管理員來維護和更新。上述三層數(shù)據(jù)庫結構還涉及出于數(shù)據(jù)獨立性的概念，已經被長時間描述為所需的數(shù)據(jù)庫屬性和一個重要的初始驅動的關系模型。在以上的結構語境里它意味著在一定程度上的改變不影響定義和高層次的接口軟件開發(fā)，并且被自動納入在更高的水平。例如，在內部水平的變化不影響編寫應用程序使用概念層次的接口，這些節(jié)省了大量的工作，否則就需要改變?？傊?，這個概念是在內部與外部之間的一級間接尋址。一方面它提供一個數(shù)據(jù)庫的共同看法，獨立在不同的外部視圖結構，另一方面它是由簡單的被存儲和管理的詳細說明的數(shù)據(jù)（內部水平）。原則上每個水平，甚至每一個外部視圖，能夠通過不同的數(shù)據(jù)模型被展現(xiàn)。在實踐中，通常一個特定的數(shù)據(jù)庫無論是外部的和概念層，使用相同的數(shù)據(jù)模型（例如，關系模型）。內部層，隱藏在數(shù)據(jù)庫管理系統(tǒng)并且取決于它的實現(xiàn)（看如下的實現(xiàn)部分），需要不同的詳細的水平，使用它自己的數(shù)據(jù)結構類型，從被暴露于數(shù)據(jù)庫管理系統(tǒng)用戶外部和概念層次結構的性質通常是不同的（例如，如上的數(shù)據(jù)模型）：當外部層次和概念都集中在服務用戶的數(shù)據(jù)庫管理系統(tǒng)，內部層次的關注是有效的實施細則。來源于：TheWikipediaRevolution[M].北京：北京科文圖書業(yè)信息技術有限公司，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