计算机科学与技术专业外文翻译--数据库

外文原文：

Database

1.1Database concept

The database concept has evolved since the 1960s to ease increasing difficulties in designing, building, and maintaining complex information systems (typically with many concurrent end-users, and with a large amount of diverse data). It has evolved together with database management systems which enable the effective handling of databases. Though the terms database and DBMS define different entities, they are inseparable: a database's properties are determined by its supporting DBMS and vice-versa. The Oxford English dictionary cites[citation needed] a 1962 technical report as the first to use the term "data-base." With the progress in technology in the areas of processors, computer memory, computer storage and computer networks, the sizes, capabilities, and performance of databases and their respective DBMSs have grown in orders of magnitudes. For decades it has been unlikely that a complex information system can be built effectively without a proper database supported by a DBMS. The utilization of databases is now spread to such a wide degree that virtually every technology and product relies on databases and DBMSs for its development and commercialization, or even may have such embedded in it. Also, organizations and companies, from small to large, heavily depend on databases for their operations.

No widely accepted exact definition exists for DBMS. However, a system needs to provide considerable functionality to qualify as a DBMS. Accordingly its supported data collection needs to meet respective usability requirements (broadly defined by the requirements below) to qualify as a database. Thus, a database and its supporting DBMS are defined here by a set of general requirements listed below. Virtually all existing mature DBMS products meet these requirements to a great extent, while less mature either meet them or converge to meet them.

1.2Evolution of database and DBMS technology

The introduction of the term database coincided with the availability of direct-access storage (disks and drums) from the mid-1960s onwards. The term represented a contrast with the tape-based systems of the past, allowing shared interactive use rather than daily batch processing.

In the earliest database systems, efficiency was perhaps the primary concern, but it was already recognized that there were other important objectives. One of the key aims was to make the data independent of the logic of application programs, so that the same data could be made available to different applications.

The first generation of database systems were navigational,[2] applications typically accessed data by following pointers from one record to another. The two main data models at this time were the hierarchical model, epitomized by IBM's IMS system, and the Codasyl model (Network model), implemented in a number of

products such as IDMS.

The Relational model, first proposed in 1970 by Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. This was considered necessary to allow the content of the database to evolve without constant rewriting of applications. Relational systems placed heavy demands on processing resources, and it was not until the mid 1980s that computing hardware became powerful enough to allow them to be widely deployed. By the early 1990s, however, relational systems were dominant for all large-scale data processing applications, and they remain dominant today (2012) except in niche areas. The dominant database language is the standard SQL for the Relational model, which has influenced database languages also for other data models.

Because the relational model emphasizes search rather than navigation, it does not make relationships between different entities explicit in the form of pointers, but represents them rather using primary keys and foreign keys. While this is a good basis for a query language, it is less well suited as a modeling language. For this reason a different model, the Entity-relationship model which emerged shortly later (1976), gained popularity for database design.

In the period since the 1970s database technology has kept pace with the increasing resources becoming available from the computing platform: notably the rapid increase in the capacity and speed (and reduction in price) of disk storage, and the increasing capacity of main memory. This has enabled ever larger databases and higher throughputs to be achieved.

The rigidity of the relational model, in which all data is held in tables with a fixed structure of rows and columns, has increasingly been seen as a limitation when handling information that is richer or more varied in structure than the traditional 'ledger-book' data of corporate information systems: for example, document databases, engineering databases, multimedia databases, or databases used in the molecular sciences. Various attempts have been made to address this problem, many of them gathering under banners such as post-relational or NoSQL. Two developments of note are the Object database and the XML database. The vendors of relational databases have fought off competition from these newer models by extending the capabilities of their own products to support a wider variety of data types.

1.3General-purpose DBMS

A DBMS has evolved into a complex software system and its development typically requires thousands of person-years of development effort.[citation needed] Some general-purpose DBMSs, like Oracle, Microsoft SQL Server, and IBM DB2, have been undergoing upgrades for thirty years or more. General-purpose DBMSs aim to satisfy as many applications as possible, which typically makes them even more complex than special-purpose databases. However, the fact that they can be used "off the shelf", as well as their amortized cost over many applications and instances, makes them an attractive alternative (Vsone-time development) whenever they meet an application's requirements.

Though attractive in many cases, a general-purpose DBMS is not always the optimal solution: When certain applications are pervasive with many operating instances, each with many users, a general-purpose DBMS may introduce unnecessary overhead and too large "footprint" (too large amount of unnecessary, unutilized software code). Such applications usually justify dedicated development.

Typical examples are email systems, though they need to possess certain DBMS properties: email systems are built in a way that optimizes email messages handling and managing, and do not need significant portions of a general-purpose DBMS functionality.

1.4Database machines and appliances

In the 1970s and 1980s attempts were made to build database systems with integrated hardware and software. The underlying philosophy was that such integration would provide higher performance at lower cost. Examples were IBM System/38, the early offering of Teradata, and the Britton Lee, Inc. database machine. Another approach to hardware support for database management was ICL's CAFS accelerator, a hardware disk controller with programmable search capabilities. In the long term these efforts were generally unsuccessful because specialized database machines could not keep pace with the rapid development and progress of general-purpose computers. Thus most database systems nowadays are software systems running on general-purpose hardware, using general-purpose computer data storage. However this idea is still pursued for certain applications by some companies like Netezza and Oracle (Exadata).

1.5Database research

Database research has been an active and diverse area, with many specializations, carried out since the early days of dealing with the database concept in the 1960s. It has strong ties with database technology and DBMS products. Database research has taken place at research and development groups of companies (e.g., notably at IBM Research, who contributed technologies and ideas virtually to any DBMS existing today), research institutes, and Academia. Research has been done both through Theory and Prototypes. The interaction between research and database related product development has been very productive to the database area, and many related key concepts and technologies emerged from it. Notable are the Relational and the Entity-relationship models, the Atomic transaction concept and related Concurrency control techniques, Query languages and Query optimization methods, RAID, and more. Research has provided deep insight to virtually all aspects of databases, though not always has been pragmatic, effective (and cannot and should not always be: research is exploratory in nature, and not always leads to accepted or useful ideas). Ultimately market forces and real needs determine the selection of problem solutions and related technologies, also among those proposed by research. However, occasionally, not the best and most elegant solution wins (e.g., SQL). Along their history DBMSs and respective databases, to a great extent, have been the outcome of such research, while real product requirements and challenges triggered database research directions and sub-areas.

The database research area has several notable dedicated academic journals (e.g., ACM Transactions on Database Systems-TODS, Data and Knowledge Engineering-DKE, and more) and annual conferences (e.g., ACM SIGMOD, ACM PODS, VLDB, IEEE ICDE, and more), as well as an active and quite heterogeneous (subject-wise) research community all over the world.

1.6Database architecture

Database architecture (to be distinguished from DBMS architecture; see below) may be viewed, to some extent, as an extension of Data modeling. It is used to conveniently answer requirements of different end-users from a same database, as well as for other benefits. For example, a financial department of a company needs the payment details of all employees as part of the company's expenses, but not other many details about employees, that are the interest of the human resources department. Thus different departments need different views of the company's database, that both include the employees' payments, possibly in a different level of detail (and presented in different visual forms). To meet such requirement effectively database architecture consists of three levels: external, conceptual and internal. Clearly separating the three levels was a major feature of the relational database model implementations that dominate 21st century databases.[13]

The external level defines how each end-user type understands the organization of its respective relevant data in the database, i.e., the different needed end-user views.

A single database can have any number of views at the external level.

The conceptual level unifies the various external views into a coherent whole, global view.[13] It provides the common-denominator of all the external views. It comprises all the end-user needed generic data, i.e., all the data from which any view may be derived/computed. It is provided in the simplest possible way of such generic data, and comprises the back-bone of the database. It is out of the scope of the various database end-users, and serves database application developers and defined by database administrators that build the database.

The Internal level (or Physical level) is as a matter of fact part of the database implementation inside a DBMS (see Implementation section below). It is concerned with cost, performance, scalability and other operational matters. It deals with storage layout of the conceptual level, provides supporting storage-structures like indexes, to enhance performance, and occasionally stores data of individual views (materialized views), computed from generic data, if performance justification exists for such redundancy. It balances all the external views' performance requirements, possibly conflicting, in attempt to optimize the overall database usage by all its end-uses according to the database goals and priorities.

All the three levels are maintained and updated according to changing needs by database administrators who often also participate in the database design.

The above three-level database architecture also relates to and being motivated by the concept of data independence which has been described for long time as a desired database property and was one of the major initial driving forces of the Relational model. In the context of the above architecture it means that changes made at a certain level do not affect definitions and software developed with higher level interfaces, and are being incorporated at the higher level automatically. For example, changes in the internal level do not affect application programs written using conceptual level interfaces, which saves substantial change work that would be needed otherwise.

In summary, the conceptual is a level of indirection between internal and external. On one hand it provides a common view of the database, independent of different external view structures, and on the other hand it is uncomplicated by details of how the data is stored or managed (internal level). In principle every level, and even every external view, can be presented by a different data model. In practice usually a given DBMS uses the same data model for both the external and the conceptual levels (e.g., relational model). The internal level, which is hidden inside the DBMS and depends on its implementation (see Implementation section below), requires a different level

of detail and uses its own data structure types, typically different in nature from the structures of the external and conceptual levels which are exposed to DBMS users (e.g., the data models above): While the external and conceptual levels are focused on and serve DBMS users, the concern of the internal level is effective implementation details.

中文译文：

数据库

1.1 数据库的概念

数据库的概念已经演变自1960年以来，以缓解日益困难，在设计，建设，维护复杂的信息系统（通常与许多并发的最终用户，并用大量不同的数据）。它已演变连同数据库管理系统，使数据库的有效处理。虽然术语数据库和DBMS 定义不同的实体，它们是分不开的：一个数据库的属性决定其支持的DBMS，反之亦然。牛津英语词典CITES[需要的引证]1962年首先使用的术语的技术报告“的数据基础。”在处理器，计算机内存，计算机存储和计算机网络等领域的技术进步，已经长大的大小，功能和性能数据库和各自的DBMS中量级。几十年来，它已经不可能是一个复杂的信息系统可以建立不正确的数据库由DBMS支持有效。现在已经蔓延到如此广泛的程度，几乎每一个技术和产品的开发和商品化的依赖于数据库和DBMS，甚至有可能也有这样的嵌入式数据库的利用率。同时，组织和企业，从小型到大型，严重依赖于为他们的业务数据库。

没有被广泛接受的确切的定义存在的DBMS。然而，系统需要提供大量的功能，作为DBMS资格。因此，其支持的数据收集需要，以满足各自的可用性需求（大致由以下要求定义）资格作为数据库。因此，数据库和其支持的DBMS 在这里被定义一套下面列出的一般要求。几乎所有的现有成熟的数据库产品在很大程度上满足这些要求，而不太成熟或者满足他们或衔接，以满足他们。

1.2数据库和数据库技术的演变

术语数据库的引进，同时可直接存取存储（磁盘和鼓）从20世纪60年代中期起。这个词代表了与过去的基于磁带的系统相反，允许共享的交互使用，而不是每日批处理。

在最早的数据库系统，效率也许是首要关心的问题，但它已经认识到，还有其他的重要目标。主要目标之一是使数据独立于应用程序的逻辑，因此，相同的数据可以提供给不同的应用。

第一代数据库系统导航，[2]应用程序通常由以下指针从一个记录到另一个访问数据。这个时候的两个主要数据模型，层次模型，由IBM公司的IMS系统的缩影，CODASYL模型（网络模型），实现的产品，如同位素稀释。

埃德加楼科德于1970年首次提出，关系模型，背离了这一传统，坚持应用程序应搜索数据的内容，而不是通过以下链接。这被认为是必要的，让数据库的内容，以发展没有固定的应用重写。关系系统处理资源放在了很高的要求，它直到20世纪80年代中期，计算机硬件变得强大到足以让他们得到广泛部署。然而，由20世纪90年代初，关系系统所有大规模数据处理应用的优势，他们在优势领

域仍占据主导地位，除了今日（2012年）。占主导地位的数据库语言是标准SQL 的关系模型，这已经影响了其他数据模型的数据库语言。

由于关系模型的强调，而不是导航，搜索，它并没有作出明确的指针形式的不同实体之间的关系，但代表他们，而使用主键和外键。虽然这是一个良好的基础查询语言，它是不太适合作为一种建模语言。出于这个原因，出现不久后（1976年）的实体- 关系模型，获得了不同的模型，数据库设计的普及。

在20世纪70年代以来的数据库技术，不断增加资源，提供从计算平台的步伐期间：特别是在快速增长的磁盘存储容量和速度（降低价格），主内存容量增加。这使得越来越大的数据库和更高的吞吐量来实现。

越来越多的限制，处理的信息是丰富的，或在结构更加多样化，比传统的“总帐书”时，被视为关系模型，其中所有的数据表的行和列的固定结构举行的刚性企业信息系统的数据：例如，在分子科学文献数据库，工程数据库，多媒体数据库，或数据库。已作出各种尝试来解决这个问题，如后关系或NoSQL的旗帜下聚集。两个值得注意的发展是对象数据库和XML数据库。关系数据库的厂商已经击退了从这些新车型的竞争，扩大自己的产品的能力，以支持更广泛的数据类型。

1.3 一般用途的DBMS

一个DBMS已经演变成一个复杂的软件系统，其发展通常需要数千人多年的发展努力。[引文需要]一些通用的DBMS，像甲骨文，微软SQL Server和IBM DB2，已经历了三十升级年或更长时间。通用数据库管理系统的目标，以满足尽可能多的应用，这通常使得他们更加复杂比专用数据库。然而，其实，他们可以用“关闭的架子”，以及他们对许多应用和实例的摊销成本，使他们有吸引力的替代（而不是一次性的发展），每当他们满足应用的要求。

在许多情况下，虽然有吸引力，通用DBMS并不总是最佳的解决方案：当某些应用与许多操作系统实例，每个拥有众多用户的普遍，通用DBMS可能会带来不必要的开销过大的“足迹”（太大量不必要的，未使用的软件代码）。这些应用程序通常证明了专门的开发。典型的例子是电子邮件系统，但他们需要具备某些DBMS的性能：在优化处理和管理电子邮件的方式，建立电子邮件系统，并不需要一个通用的DBMS功能的重要部分。

1.4 数据库的机器和设备

在20世纪70年代和20世纪80年代尝试建立与数据库系统集成的硬件和软件。的基本原则是，这种一体化会以较低的成本提供更高的性能。例子是年初发行的Teradata，IBM IBMSystem/38中，布里顿李公司的数据库机器。数据库管理的硬件支持的另一种方法是ICL的水产科学研究院加速器，硬件磁盘控制器与可编程的搜索功能。从长远来看这些努力失败，因为专门的数据库机器不能保持与通用计算机的飞速发展和进步的步伐。因此，现在大多数数据库系统是通用的硬件上运行，使用通用的计算机数据存储的软件系统。然而，这种想法仍然奉行像Netezza和甲骨文（Exadata的）一些公司对某些应用。

1.5 数据库的研究

数据库的研究一直是积极的和多样化的地区，与许多专业，处理与数据库的概念在20世纪60年代初期以来进行的。它拥有强大的关系数据库技术和DBMS 产品。数据库研究组研究和开发公司已采取的地方（例如，特别是在IBM研究中心的技术和理念，谁贡献几乎任何现有的DBMS今天），科研院所和学术界。研究已经完成，通过理论和原型。研究和数据库相关的产品开发之间的互动一直非常富有成效的数据库领域，并从它出现的许多相关的关键概念和技术。值得注意的是关系和实体关系模型，原子事务的概念和相关的并发控制技术，查询语言和查询优化方法的RAID，更多。数据库的几乎所有方面的研究提供了深刻的洞察力，但并不总是一直务实，有效的（不能和不应该永远是：研究是探索性的，并不总是导致公认的或有用的想法）。最终，市场力量和实际需要确定问题解决方案及相关技术的选择，也通过研究提出的那些。但是，偶尔，而不是最好的，最优雅的解决方案，赢得（例如，SQL）。沿着历史的DBMS和各自的数据库，在很大程度上，已经这样的研究成果，而真正的产品的要求和挑战，引发了数据库的研究方向和子区域。

数据库研究领域有几个显着的专用学术期刊（例如，数据库ACM交易系统TODS，数据和知识工程，DKE等）和年度会议（例如，ACM坦帕湾，ACM SIGMOD，VLDB，IEEE ICDE，多），以及活跃相当异构（明智主题）世界各地的研究团体。

1.6数据库体系结构

可以查看数据库架构（以区别于DBMS体系结构;见下文），在一定程度上，作为一个数据模型的扩展。它是用来方便地回答不同的最终用户的要求，从同一个数据库，以及其他福利。例如，某公司财务部门需要全体员工的付款细节，作为公司的费用的一部分，而不是其他许多细节的员工，是人力资源的部门的利益。因此，不同的部门需要不同的意见，该公司的数据库，既包括支付员工可能在不同的细节水平，（在不同的视觉形式提交）。为了满足这些要求的有效的数据库体系结构包括三个层次：外部，概念和内部。明确区分三个层次是主宰21世纪的数据库关系数据库模型实现的主要功能。[13]

每个最终用户的类型，了解其各自的相关数据在数据库中，也就是说，不同的需要最终用户的意见组织外部级别定义如何。一个数据库可以有任何的若干意见，在外部层面。

概念层次结合成一个有机的整体，全局视图外部的各种意见。[13]，它提供的所有外部意见的共同分母。它包括所有的最终用户所需的通用数据，也就是说，所有的任何视图可以导出/计算数据。它提供了最简单的方式，如通用数据，包括数据库恢复骨。正是出于各种数据库的最终用户的范围，并提供数据库应用程序开发和建立数据库的数据库管理员定义。

国内一级（物理层），是作为一个内DBMS的数据库（见下文实现“一节）实施的一部分的事实问题。它关注的是成本，性能，可扩展性和其他业务事项。

它处理与存储的概念层次的布局，提供配套的存储结构，如索引，以提高性能，偶尔存储数据的个人意见（物化视图），通用数据计算，如果存在这样的冗余性能的理由。平衡所有的外部意见的性能要求，它可能是冲突的企图优化整体数据库的使用其所有使用数据库的目标和优先事项。

所有三个层次的维护和更新，根据不断变化的需求，他们也经常参加在数据库设计的数据库管理员。

还涉及上述三个层次的数据库架构和数据独立性的概念已被描述为长的时间作为一个理想的数据库属性的初始关系模型的主要动力之一的动机。在上述体系结构的背景下，它是指在一定的水平所做的变更不会影响与更高级别的接口定义和开发的软件，并自动被纳入在较高的水平。例如，在内部水平的变化不影响使用概念层次的接口，从而节省了重大变化的工作，否则将需要编写的应用程序。总之，概念是一种间接的内部和外部之间的水平。一方面，它提供了数据库的一个共同的看法，不同的外部视图结构的独立，另一方面，它是由简单的数据是如何存储或管理（内部水平）的细节。原则上每个级别，甚至每一个外部视图，可以由不同的数据模型。在实践中通常是一个给定的数据库管理系统使用外部和概念水平相同的数据模型（例如关系模型）。内部的水平，这是藏在里面的DBMS，取决于它的实施（见下文实现“一节），需要不同程度的细节，并使用自己的数据结构类型，通常从外部和概念水平的结构性质不同DBMS用户（例如，上面的数据模型）：虽然外部和概念层面主要集中在服务DBMS用户，关注的是有效的内部实施细则。