phase 计算机翻译,英译中求助：计算机外文杂志期刊，请大师帮忙翻译一下

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

A Logical Design Tool for Relational Databases

Here's a way to prevent anomalies from affecting the design of your relational data base.

New trends in software development point to the automation of various phases of the software life cycle, particularly the design phase. A typical example is computer-aided software engineering technology,which provides tools to assist in software development. In the past few years, interest has grown in the development of database-management systems (DBMSs) based on the relational model (see the accompanying box for definitions and notations).

Systems for managing large-scale databases under the relational model(for example, Oracle) have become commercially available, which makes the value of a design tool for the relational model obvious. This fact motivated us to implement the Logical Design Tool (LDT), which can also be used as an educational tool for the relational database. Using this tool during database design can detect certain problems that arise when the data is manipulated. An example is a cycle in a schema that leads to ambiguous interpretation of queries.The major problem, however, is to come up with a particular normal-form design (such as a third normal form) through the process of decomposition. Decomposing a relation scheme into several relation schemes prevents the occurrence of anomalies Consider the following Suppliers relation scheme taken from Ullman.

SUPPLIERS (SNAME, SADDRESS, ITEM, PRICE)

We can see several problems with this scheme:

*Redundancy. The address of the supplier repeats each time an item is supplied.

*Potential inconsistency (update anomalies). Because of the redundancy,users can update the address for a supplier in one tuple and leave it fixed in another. Thus, users may not have a unique address for each supplier as they feel intuitively that they should.

*Insertion anomalies. Users cannot record an address for a supplier if that supplier does not currently provide at least one item. Null values can be used for the Item and Price components of a tuple for that supplier.However, when users enter an item for that supplier,they may not remember to delete the tuple with the null values. In addition, if Item and Sname form a key for the relation, it might be awkward or impossible to look up tuples with null values in the key.

*Deletion anomalies. If users delete all the items supplied by one supplier, they unintentionally lose track of its address.

The Relational Database Model

Here we present some brief definitions and notations of the relational database used in this article.

Definitions

Conceptually, a table can represent a relation.Each row represents a tuple, and each column represents an attribute. The set of attribute names for a relation is called the relation scheme.In Table A, we see a relation whose attributes are S#, Sname,Status, and City. The tuple is {S1, Smith, 20, London].The relation scheme for this relation is SUPPLIERS (S#, Sname, Status, City). Any set of one or more attributes that uniquely identifies the tuples is called a candidate key (like S#), and the attribute selected for the relation is called the primary key (or just key). A relational schema is composed of a set of relation schemes.