【文章內(nèi)容簡介】 om the low level (close to the machine) details of data organization. We will not discuss details of specific PC DBMS software packages here． Let us summarize in the following the strengths and weaknesses of personal puter database software systems： The most obvious positive factor is the user friendliness of the software. A user with no prior puter background would be able to use the system to store personal and professional data, retrieve and perform relayed processing. The user should, of course, satiety himself about the quality of software and the freedom from errors (bugs) so that investmerits in data arc protected. For the programmer implementing applications with them, the advantage lies in the support for applications development in terms of input screen generations, output report generation etc． offered by theses stems． The main negative point concerns absence of data protection features． Unless encrypted, data cane accessed by whoever has access to the machine Data can be destroyed through mistakes or maliciousintent. The second weakness of manv of the PCbasedsystems is that of performance. If data volumes growup to a few thousands of records， performance couldbe a bottleneck． For organization where growth in data volumesis expected, availability of, the same or patiblesoftware on large machines should be considered. This is one of the most mon misconceptionsabout database management systems that are used inpersonal puters． Thoroughly prehensive andsophisticated business systems can be developed indBASh, Paradox and other DBMSs． However, theyare created by experienced programmers using theDBMS39。s own programming language. That is not the same as users who create and manage personal filesthat are not part of the mainstream pany system． Transaction Management of Database The objective of longduration transactions is to model longduration, interactive Database access sessions in application environments． The fundamental assumption about shortduration of transactions that underlies the traditional model of transactions is inappropriate for longduration 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 userinitiated aborts or system failure situations． The objective of a transaction model is to provide 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． Scrializability 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 transaction”that doesn?t provide a basis for automatically enforcing database consistency is not really a transaction. To be sure, a longduration transaction need not adopt serializability as its consistency criterion． However. there must be some consistcricv criterion． Version System Management of Database Despite a large number of proposals on version support in the context of puter 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 databases, it may be necessary to manage not only versions of single objects (. a software module, document, but also versions of a collection of objects (. a pound document, a user manual， etc． and perhaps even versions of the schema of database (. 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 n