数据库外文翻译

Database

A database may be defined as a collection of interrelated data stored together with as little redundancy as possible to serve one or more applications in an optimal fashion; the data are stored so that they are independents of programs which use the data; a common and controlled approach is used in adding new data and in modifying and retrieving existing data within the data base one system is said to contain a collection of databases if they are entirely separate in structure.

The restructuring should be possible without having to rewrite the application program and in general should cause as little upheaval as possible the ease with which a database can be changed will have a major effect on the rate at which data-processing application can be developed in a corporation.

The term data independence is often quoted as being one of the main attributes of a database int implies that the data and the may be changed without changing the other, when a single setoff data items serves a variety of applications, different application programs perceive different relationships between the data items, to a large extent database organization is concerned with the as how and where the data are stored.

A database used for many applications can have multiple interconnection referred to as entities. An entity may be a tangible object or no tangible if it has various properties which we may wish to record. It can describe the real world. The data item represents an attribute and the attribute must be associated which the relevant entity. We relevant entity we design values to the attributes one attribute has a special significance in that it identifies the entity.

Logical data description is called a model.

We must distinguish a record and a record examples, when talking about all personnel records when it is really a record type, not combined with its data value.

A model is used to describe the database used storage in the database data item type and record types of general charts, subschema paragraph refers to an application programmer view of data, many different patterns can get from one mode. The schema

and the subschema are both used by the database management system the primary function of which is to serve the application programs by execution their data operations.

A DBMS will usually be handling multiple data calls concurrently, it must organize its system buffers so that different data operations can be in process together, it provides a data definition language to specify the conceptual schema and most likely some of the details regarding the implementation of the conceptual schema by the physical schema the describe the conceptual schema in terms for a “data model”.

The choice of a data model is a difficult one, since it must be such enough in structure to describe significant aspects of the real world, yet it must be possible to determine fairly automatically an efficient implementation of the conceptual conceptual schema by a physical schema. It should be emphasized that while a DBMS might be used to build small databases many databases involve millions of bytes and an inefficient implementation can be disastrous.

The hierarchical and network structures have been used for DBMS since the 1960’s . the relational structure was introduced in the early 1970’s.

In the relational model two-dimensional tables represent the entities and their relationships every table represents an entities are represented by common columns containing values from a domain or range of possible values .The end user is presented with a simple data model his and her request and don not reflect any complexities due to system-oriented aspects a relational data model is what the user sees , but it is mot necessarily what will be implemented physically.

The relational data model removes the details of storage structure and access strategy from the user inter-face the model providers a relatively higher degree of data to make use of this property of the relational data model however, the design of the relations must be complete and accurate. Although some DBMS based on the relational data model are commercially available today it is difficult to provide a complete set of operational capabilities with required efficiency on a large scale it appears today that technological improvements in providing faster and more reliable hardware may answer the question positively.

The hierarchical data model is based no a tree-like structure made up of nodes and branches a node is a collection of data attributes describing the entity at that opine the highest node of the hierarchical.

A hierarchical data model always starts with a root node every node consists of one or more attributes describing the entity at that node dependent nodes can follow the succeeding levels the mode in the receding level becomes the parent node of the new dependent nodes a parent node can have one child node as a dependent or many children nodes the major advantage of the hierarchical data model is the existence of proven database management systems that use the hierarchical data model as the basic structure there is a reduction of data dependency but any child mode is accessible only in a clumsy way this often results in a redundancy in stored data.

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. 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.

Database 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, related Concurrency,control,techniques,Query,languages,and Query,optimization metho ds, 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 and annual conferences(e.g.,ACM PODS, VLDB, IEEE ICDE, and more), as well as an active and quite heterogeneous (subject-wise) research community all over the world. Functional requirements

Certain general functional requirements need to be met in conjunction with a database. They describe what is needed to be defined in a database for any specific application.

Defining the structure of data: Data modeling and Data definition languages

The database needs to be based on a data model that is sufficiently rich to describe in the database all the needed respective application's aspects. A data definition language exists to describe the databases within the data model. Such language is typically data model specific.

Manipulating the data: Data manipulation languages and Query languages

A database data model needs support by a sufficiently rich data manipulation language to allow all database manipulations and information generation (from the data) as needed by the respective application. Such language is typically data model specific. Protecting the data: Setting database security types and levels

The DB needs built-in security means to protect its content (and users) from dangers of unauthorized users (either humans or programs). Protection is also provided from types of unintentional breach. Security types and levels should be defined by the database owners.

Database design

Database design is done before building it to meet needs of end-users within a given application/information-system that the database is intended to support. The database design defines the needed data and data structures that such a database comprises. A design is typically carried out according to the common three architectural levels of a database (see Database architecture above). First, the conceptual level is designed, which defines the over-all picture/view of the database, and reflects all the real-world elements (entities) the database intends to model, as well as the relationships among them. On top of it the external level, various views of the database, are designed according to (possibly completely different) needs of specific end-user types. More external views can be added later. External views requirements may modify the design of the conceptual level (i.e., add/remove entities and relationships), but usually a well

designed conceptual level for an application well supports most of the needed external views. The conceptual view also determines the internal level (which primarily deals with data layout in storage) to a great extent. External views requirement may add supporting storage structures, like materialized views and indexes, for enhanced performance. Typically the internal layer is optimized for top performance, in an average way that takes into account performance requirements (possibly conflicting) of different external views according to their relative importance. While the conceptual and external levels design can usually be done independently of any DBMS (DBMS-independent design software packages exist, possibly with interfaces to some specific popular DBMSs), the internal level design highly relies on the capabilities and internal data structure of the specific DBMS utilized (see the Implementation section below).

A common way to carry out conceptual level design is to use the Entity-relationship model (ERM) (both the basic one, and with possible enhancement that it has gone over), since it provides a straightforward, intuitive perception of an application's elements and semantics. An alternative approach, which preceded the ERM, is using the Relational model and dependencies (mathematical relationships) among data to normalize the database, i.e., to define the ("optimal") relations (data record or tupple types) in the database. Though a large body of research exists for this method it is more complex, less intuitive, and not more effective than the ERM method. Thus normalization is less utilized in practice than the ERM method.

The ERM may be less subtle than normalization in several aspects, but it captures the main needed dependencies which are induced bykeys/identifiers of entities and relationships. Also the ERM inherently includes the important inclusion dependencies (i.e., an entity instance that does not exist (has not been explicitly inserted) cannot appear in a relationship with other entities) which usually have been ignored in normalization..

Another aspect of database design is its security. It involves both defining access control to database objects (e.g., Entities, Views) as well as defining security levels and methods for the data itself.

数据库

一个数据库可以被定义成一个相关数据的集合，这个集合尽可能小的冗余为一个或多个应用程序在最理想的方式下服务，存贮数据的目的是使他们与使用数据的程序独立，一种相同的控制方法用于数据库更新数据和修改，恢复已存在的数据，如果一个系统在结构上完全分离，则他们被称为一个数据库集合。

大多数数据库的最主要特点之一是他们需要不断的更新和增加。当数据类型和应用被增加时，简单重构必须是可能的，重组织应不需要重新写应用程序，总体上应当尽可能小的变化，这种不费力的改变数据库将在数据处理的速度上产生很大的影响。

数据独立这个术语经常提出作为一个数据主要属性之一，它是指数据和使用数据的应用程序相互独立，改变一项时不用改变另一项，当一个单一的数据集合服务于不同的应用时，不同的应用程序感知数据项与记录之间的管理说明相联系，也和数据是怎样存贮的和存在哪里有关，在许多应用程序的数据之间有很多种内在的联系。

关于我们所存信息的项是一个实体，一个实体可以是一个实在的物体或抽象的事物，它有我们希望记录的各种性质，它能描述一个真实的世界，数据项代表一个属性，该属性与有关的实体联合。我们将属性设计成值，一个属性有一个特殊意义，据此而定义一个实体。

逻辑数据库的描述叫做一个模式。

我们必须区别一个记录和一个记录的事例，当谈论到全体人员的记录时它是一个真正的记录类型，而不是与它相结合的数据值。

一个模型用于描述数据库中的所用存贮在数据库中的数据项类型和记录类型的总体图表，子模式项指的是一个应用程序员观点下的数据，许多不同的模式可以从一个模式中得到。模式和子模式是由数据库管理系统使用的，数据库管理系统的主要作用是执行数据操作时服务于应用程序。

一个数据库管理系统通常是用语同时处理多个数据调用，它必须组织系统缓冲使不同的数据操作能够一起处理，它提供种数据定义语言经指定概念模式，并且很可能还包括使用物理模式实现概念模式的一些细节，定义语言是一种高级语言，能

够让你描述概念模型，术语为数据模型。

数据模型选择是很困难的，因为它必须有丰富的足够结构以描述真实世界有意义的各个方面，并且必须通过物理模式有能力、自动地决定概念模式的实现，必须强调，当一个数据库处理系统用于建立一个小数据库中时，许多数据库包括了上万字节，所以无效的执行可能是灾难性的。

逻辑模式被定义为数据模式，带有附加在其上的特别折数据库管理系统的基本结构，目前，数据库管理系统有，三种主要的基本结构，他们是：关系结构，层次结构，网络结构。

层次型和网络型从20世纪60年代已应用于DBMS中，关系模型在20世纪70年代早期开始有所介绍。

在关系模型中，实体和他们的关系用二维表格表示，每一个表格代表一个实体，其值是有一定范围，最终用户被提供一个简单数据模型，他或她需求由信息内容的描述而明确的表达，不用表示面向系统的各方面复杂的情况，关系数据模型似乎用户所看到的，但不必知道物理的实现。

数据模型在用户界面上排出了存贮结构和存取策略的细节，模型提供了一种高层次的数据关系，然而为了正确的使用关系数据模型，关系的设计必须是完备的和正确的。尽管目前一些基于关系数据模型的数据库管理系统实行商业化应用，但它很难在大规模范围内按需求的目标提供一套完整的操作能力，现在提供快速且稳定的硬件方面的技术改进才有可能真正回答这个问题。

层次型数据模型是基于数型结构的，由结点和数值组成，一个结点是描述此点上实体属性的数据集合。

层次型数据结构模型总是从根结点开始的，第每个结包括描述此结点的一个或多个属性，相关结点可以在下一层上，上层的结点变成新的相关结点或父结点，一个父结点可有一个相关子结点或多个子结点，层次数结点才能存取，许多的关系只能用笨拙的方法实现，这常常引起存贮数据的复杂。

网状数据模型将企业的实体连接到网络中。在网状数据模型中，一个数据库包括大量区域，一个区域包括一些记录，而一个记录可以包含字段，一个集合是记录群，可以在一个区域中，或跨越一些区域，一个集合类型基于所有者的记录类型和成员记录类型，许多在真实生活中发生得很频繁的关系，可以很容易的实现，网状

数据模型是和有复杂的，应用程序员必须很熟悉数据库的逻辑结构。

为满足某一部门中多个用户多种应用的需要，按照一定的数据模型在计算机系统中组织、存储和使用的互相联系的数据集合。

带有数据库的计算机系统，除具备一般的硬件、软件外，必须有用以存储大量数据的直接存取存储设备、管理并控制数据库的软件——数据库管理系统(DBMS)、管理数据库的人员——数据库管理员 (DBA)。这样的数据、硬件、软件和管理人员的总体构成数据库系统。数据库仅是数据库系统的一个组成部分。

自20世纪60年代以数据库的概念诞生以来，数据库技术日益演变，以解决复杂的设计、建筑，和维护复杂信息系统（通常有许多并发用户,和各种各样的数据）。它与数据库管理系统共同演化，使得数据处理更加有效合理。尽管数据库和数据库管理系统是定义不同的实体，但它们是不可分割的：一个数据库的性能是由数据库管理系统支撑的，反之亦然。随着计算机处理器，内存，计算机和计算机网络、大小、功能和性能等技术领域的不断进步，数据库及对应的数据库系统取得飞速的发展。几十年来，因为有了适当的数据库支持的数据库管理系统，复杂的信息系统便得以建立。利用数据库管理数据在当前社会已得以普及，几乎所有的技术和产品都依赖于数据库和数据库管理系统的发展和商业化，甚至可能有这样的嵌入其中。此外，公司集团从小型到大型，各类工作运行，很大程度上都取决于数据库的操作。

目前，并没有一个可普遍接受的有关数据库管理系统的确定定义，只要一个系统可以完成提供大量数据的功能，便有资格作为一个数据库管理系统。一个数据库（广义定义下），其数据收集满足可用性要求，便有资格作为一个数据库。这便是一个数据库及其配套数据库管理系统一般要求。大部分的现有成熟的数据库产品在很大程度上，要么满足所需要求，要么接近要求。

从1960年代数据库概念产生以来，数据库的研究一直是一个活跃的、多样化的课题，形成许多的专门化的研究领域。它具有很高的关系数据库技术和很多的数据库管理系统产品。数据库的研究高度发展（例如，尤其是在研究技术，理念和任何数据库管理系统存在的今天），已逐渐形成了相关的研究所，学术界和研究公司。通过理论和原型设计，其研究已经能够完成。从它出现使许多相关的关键概念和技术之间的相互作用的研究，和相关产品的开发，形成了非常有成效的数据库领域。现在值得注意的研究是，关系和实体关系模型，原子事务的概念和相关的并发控制

技术，查询语言和查询优化方法。研究提供了几乎所有方面的数据库，但并不是总是有效的（并且不能也不应该永远是：研究是探索性的，而不是总是接受已有想法）。研究通常是通过市场和实际需要，确定和选择问题解决方案及相关技术。然而，有时候并不能得到最好的、最完美的研究结果，但纵观数据库研究发展历史，在很大程度上，正是是由于这样的研究结果，和对产品的需求的满足，引发了数据库的多元化的研究方向和领域。

数据库研究领域中有几个著名的专门学术期刊（如，美国计算机学会数据库s，数据和知识搜索引擎等）和年度会议（关于通讯、计算机、电子的、集成电路等），还有在世界各地研究各异的研究机构。

功能要求

通过数据库，使得某些特殊功能需要得以满足，其完成了具体应用的中的各项数据的定义。

定义数据结构：数据建模和数据定义语言

满足数据库需要的基础上的建立的数据模型，能够描述数据库的各方面所需。数据定义语言用来说明数据库内的数据模型。这种语言通常是具体的数据模型。

数据操作语言和查询语言

数据库数据模型需要一个足够丰富的数据操作语言，允许所有的数据库操作和信息的产生。这种语言通常是具体的数据模型。

数据保护：设置数据库安全的类型和层次

数据库需要内置的安全手段来保护其内容的危险。安全类型和层次的定义应该由数据库所有者提供。

数据库设计

数据库设计的目的是支持和满足用户在一个特定的应用信息系统中的最终需求。这样一个数据库包括数据库设计定义所需的数据和数据结构。设计通常是根据共同进行的三个体系结构层次数据库：首先是概念层设计，它定义了整体图片和视图的数据库，并反映了所有的现实世界的元素(实体)数据库模型，以及它们之间的关系；在其顶部的外在层次上各种，数据库设计是根据用户的特定需求，更多的外部视图可以在以后添加；外部视图的需求，可能导致设计概念层次的修改(例如,添加/删除实体)，但通常来说，一个精心设计的概念层次的一个很不错的应用程序，

支持大多数所需的外部视图。概念视图在很大程度上也决定了内部水平，外部视图需求会增加支持存储结构,如物化视图和索引,提高需求。通常内部层为优化最佳性能，会根据它们的相对重要性，考虑性能要求不同的外部视图。而设计的概念和外部水平，通常可以独立完成任何数据库管理系统，内部设计高度依赖于其功能和内部数据结构中数据库管理系统的使用。

常见的一个来完成概念的层次设计的方式是使用实体关系模型，因为它提供了一个简单，直观的方式，而之前使用的是关系模型和依赖模型之间的正常化的数据库。通过大量的研究，证实这种方法是更复杂，更直观的，但不是更有效地的方法。因此正常化是较少使用的方法。

另一方面，数据库设计的安全问题，它涉及两个定义访问控制的数据库对象（例如，实体，视图）以及确定安全水平的方法和数据本身。