该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
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.
本文发布于:2024-01-31 03:09:14,感谢您对本站的认可!
本文链接:https://www.4u4v.net/it/170664175524901.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
留言与评论(共有 0 条评论) |