Page 29 - AIS access_chang_ingraham

DATABASE ANOMALIES AND NORMALIZATION 27

Inventory Table (Item #, Inventory Description, Inventory Cost, Purchase #, Sale #)
Cash Table (Account #, Account Type, Balance)

Sale Table (Sale #, Sale Date, Sale Amount, Payment Type, Customer ID, Account #)

Purchase Table (Purchase #, Purchase Date, Purchase Amount, Artist ID)

Cash Disbursement Table (Check #, Disbursement Date, Payment Amount,
Artist ID, Account #)

Artist Table (Artist ID., Artist Name, Artist Address, Artist City, Artist State, Artist
ZIP Code, Artist Phone #, Artist Email)
Customer Table (Customer ID, Customer Name, Customer Address, Customer
City, Customer State, Customer ZIP Code, Customer Phone #,
Customer Email)
Purchase-Cash Disbursement Table (Purchase #, Check #)

DATABASE ANOMALIES AND NORMALIZATION

Basic Concepts and Definitions

During logical data modeling, we often use general business knowledge and the under-
standing of the specific company to determine which attributes should be included in dif-
ferent tables. In general, after using the proper steps to create an REA data model (the log-
ical design), the design of a database should not have serious flaws. However, before pro-
ceeding with physical design, we may want to validate the logical design. Normalization
is a tool to validate and improve a logical design to satisfy database requirements and to
avoid unnecessary duplication of data. It is the process of decomposing tables with anom-
alies to produce well-structured (often smaller) tables.
Three anomalies may occur when a table is not well designed. The update anomaly
causes problems in updating a record. That is, updating a data value of one record needs to be
done many times. Data inconsistency may occur due to this anomaly. The insert anomaly
causes difficulty, sometimes impossibility, to insert new data into a table. The delete anom-
aly involves unintended loss of data that arises when deleting a row in a table. The following
vendor table showing data from part of its entire table is used to explain these anomalies. The
logical design of this original table presented in Figure 2-7 is: Vendor Table 1 (Vendor#,
Vendor Name, Vendor Address, Contact Name, Phone#, Item#, Descliption, Unit Price).
Since Vendor# is the primary key of this table, adding and deleting records should be
based on Vendor#. This vendor table has update anomalies. For example, if we want to
update the description of item K-8 from DVD player to Sony DVD, we have to search the
entire table and change every occurrence of that description. Overlooking one row would
create inconsistency in the database. This table also has insert anomalies. For example, if the
company explored a few new models of the iPod and would like to enter the information into
the database, it is not possible until the company finds a local vendor of the specific model.
This is because the primary key of the table is Vendor#. According to the entity integrity rule,