their updates．However, when updated is to benecked into the shared database, it may have to be checked in as a new version, necessitating version management. Further, 'when data in a private data-base references data in the shared data，or vice versa, a private database is not really disconnected from the shared database. For example, the evaluation of query in general will require the database system to access both a private database and the shared data-base, even if the query may have been formulated against a private database．The multiple-database model is more appropriate than the single-database model in an environment where it is easy to determine in advance logical partitions of the database that correspond to work to be performed.

The single-database model has received considerably more attention than the multiple- database model．The focus of research into single-database model has been on addressing the twin problem of long waits and loss of work that the long duration of transactions brings about.

The single-database model requires the intro-diction of a notion of database consistency, and protocols for concurrency control and recovery, that are different from those supported in traditional database systems．If a \notion of database consistency is to be supported (I．c. the database system is to enforce it automatically), there are bound to be” conflict\situations where one transaction comes into an access conflict against some other transaction. If await is to be avoided，some means of a negotiated settlement of the conflict must be provided, thereby dragging the users into the details of concurrency control．The single-database model is more appropriate-ate than the multiple-database model in an environment where it is difficult to determine in advance logical partitions of the database that correspond to work to be performed, and the users closely cooperate.

The objective of long-duration transactions is to model long-duration, interactive Database access sessions in application environments．The fundamental assumption about short-duration of transactions that underlies the traditional model of transactions is inappropriate for long-duration transactions．The implementation of the traditional model of transactions may cause intolerably long waits when transactions aleph to acquire locks before accessing data, and may also cause a large amount of work to be lost when

transactions are backed out in response to user-initiated aborts or system failure situations．

The objective of a transaction model is to pro-vide a rigorous basis for automatically enforcing criterion for database consistency for a set of multiple concurrent read and write accesses to the database in the presence of potential system failure situations．The consistency criterion adopted for traditional transactions is the notion of scrializability．Scrializa-bility is enforced in conventional database systems through the use of locking for automatic concurrency control, and logging for automatic recovery from system failure situations．A \doesn’t provide a basis for automatically enforcing data-base consistency is not really a transaction. To be sure, a long-duration transaction need not adopt seri-alizability as its consistency criterion．However. there must be some consistcricv criterion．

Despite a large number of proposals on version support in the context of computer aided design and software engineering, the absence of a consensus on version semantics has been a key impediment to version support in database systems．Because of the differences between files and databases, it is intuitively clear that the model of versions in database systems cannot be as simple as that adopted in file systems to support software engineering．For data-bases, it may be necessary to manage not only versions of single objects (e.g. a software module, document, but also versions of a collection of objects (e.g. a compound document, a user manual，etc．and perhaps even versions of the schema of database (c.g. a table or a class, a collection of tables or classes)．

Broadly, there are three directions of research and development in versioning．First is the notion of a parameterized versioning\，that is, designing and implementing a versioning system whose behavior may be tailored by adjusting system parameters This may be the only viable approach, in view of the fact that there are various plausible choices for virtually every single aspect of versioning．The second is to revisit these plausible choices for every aspect of versioning, with the view to discarding some of themes either impractical or flawed. The third is the investigation into the semantics and implementation of versioning collections of objects and of versioning the database schema.

数据库的空间组织

二十年来空间数据管理一直是数据库研究领域的活跃区，研究的焦点集中在发展存储和索引空间数据的数据结构上。但是，没有商业数据库系统直接为确定和存储空间数据提供设备，明确地表达以空间数据为研究条件的询问。我们相信下列条件是一些相关问题，在这些问题上，应把焦点集中在近期研究，（按照重要程度和迫切程度排列） 第一，关系询问最恰当技术，需要扩展以应付空间询问，也就是说，对包含查询条件的询问，需要得以发展。

第二．对于迄今提出的一些更有希望的数据结构和索引结构有关效率的实验有一效性，需要做更多的工作，还要考虑涉及面很广的一套操作，而不仅仅是迄今进行的‘有限的’效率研究方面被作典型使用的七个操作。

第三，很难在单个数据库系统内加入空间索引的多个数据结构和对十各种各样空间应用有的所有空间操作员。因此建立一个数据库是很理想的，这样将会尽可能容易地用额外的数据结构和空间操作员来扩大此系统。 数据库的查询登记和修改

如果数据库管理系统提供一种方法来相互作用地进入和修改数据库，同时查询数据库，这种方法就为管理个人数据库创造了条件。但是，它不能自动留下一串查账行动，也不能在多用户组织中提供那种必要的控制。只有当一套应用程序为每一个数据进入和修改功能设定客户规格时，才有可能得到这些控制。

当前，执行数据库系的一些功能的个人计算机软件一直很流行。个人计算机是供个人信息存储和处理而用。这些机器也广泛地被一些小企业、职业家如建筑师，医师、工程师、律师等等所使用。从使用意图的性质看，这些机器上的数据库系统没有正式数据库系统的一些要求。由于不需要数据分享，也不需要同时操作。软件也就不那么复杂。安全和整体维护也不那么重要，甚至没有随着数据容量变性能效率也不那么重要。事实上，数据库系统唯一重要的方面是数据独立。正如以前所述，数据独立是指在辅助存储器上，应用程序和用户询问不必知道数排的物理组织。这个方面的重要性，尤其对个人计算机用户来说，大大简化了数据库的使用。用户能够高层次地存储，存取和操纵数据，并且能够完全不受数据组织低层次细节的影响。在这里我们将不讨论一个特定个人计算机数据库管理系统软件包细节。我们将

在下面总结一下个人计算机数据库软件系统的优缺点：

最明显的积极方面是软件的用户友好型。一个事先不了解计算机知识的用户能够使用该系统来储存个人和职业数据，检索和执行有关处理。当然，用户应该使自己对软件质量感到满足，高质量的软件仗数据的出错率减少从而使数据投资 得到保护。

对于完成应用的程序员而言，这个优点存在于支持这些系统所提供的在输入屏幕产生，输出报告产生方面的应用发展。

主要消极点是缺少数据保护特征。除非被译成密码，数据不能被任何接触机器的人所存取。数据也能由于错误或被怀有恶意的人毁掉。以个人计算机为基础的许多系 统的第二个缺点是效率方面的缺点。如果数据发展到几千个记录，效率问题可能是一个难关。 由于数据容量的增长是一种发展趋势，所以应该考虑在较大的权器上获得相同或相容的软件。

这是对用个人计算机数据库管理系统的最常见的错误概念之一：高综合和复杂的商业系统可以在dBASE，Paradox和其它数据库誉理系统中得以发展。但是，这些商业系统是由富有经验的程序设计员通过使用数据库管理系统专用的程序语言而建立的，这与建立和管理不是公司主要系统部分的个人文件的用户有所不同。 数据的安全性和独立性

数据安全防止未经批准的用户阅览和修改数据库。通过使用密码，用户才允许接近整个数据库或叫子结构的数据库子集合。例如，一个雇员数据库装有关于雇员个人的全部数据，但是只允许一组用户看一个工资单数据，而其他用户只允许看工作历史和医疗方面的数据。

数据库管理系统通过阻止一六以上用户在相同时间更改同一记录的方法来保持数据库的完整。数具库管理系统能够防止副本记录进入数据库内。例如，不允许具有同一关键字段的两个客户进入数据具内。

当一个数据库管理系统被使用时，有关数据管理组织的详细情形不必被建立在每一个应用程序中：应用程序通过文件名向数据库管理系统要数据。例如，一个有代码鸭 表达式“将客户名称和应付余额给 我”会被送进数据库管理系统中。 如果没有数据管理系统，程序员必须给程序中记录的全部结构留下空间数据结构的任何变化要求所有的应用程序作相应的变化。

多个数据库模式

多个数据库模式是通过共享的和专用的数据库结构来回检查数据的输入结果和输出纤果