CHAPTER 9 DATABASE MANAGEMENT SYSTEMS
CHAPTER 9 DATABASE MANAGEMENT SYSTEMS
CHAPTER 9 DATABASE MANAGEMENT SYSTEMS
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>CHAPTER</strong> 9<br />
<strong>DATABASE</strong> <strong>MANAGEMENT</strong> <strong>SYSTEMS</strong><br />
REVIEW QUESTIONS<br />
1. Database planning, design, implementation, operation and maintenance, and change<br />
and growth.<br />
2. The users, the database management system, the database administrator, and the<br />
physical database structures.<br />
3. The primary difference between the network and hierarchical models is in the parentchild<br />
relationship. The network model allows a child file to have multiple parents. The<br />
hierarchical model permits a child to be associated with only one parent record.<br />
4. a. Less data redundancy<br />
b. Single update of data<br />
c. Current values for all user applications<br />
d. Task-data independence.<br />
5. Program development, backup and recovery, database usage reporting, and<br />
database access.<br />
6. One level is the schema, which is the conceptual view of the data. The schema<br />
describes the entire database, and it represents the database logically. The second<br />
level is the internal view which is the physical arrangement of the records. At this<br />
level, the physical data records are described as well as linkages between files. The<br />
next level is the subschema, which is the external view of the database that specific<br />
users have authorization to use. This is also called the user view. This is the level<br />
that users find of most interest.<br />
7. The primary key is a table attribute the value of which is unique to the record. It is a<br />
unique identifier.<br />
8. Logically related tables need to be physically connected to achieve the associations<br />
described in the data model. This is accomplished by embedding the primary key of<br />
one table into the related table as a foreign key.<br />
9. The data dictionary describes every data element in the database. The data<br />
dictionary enables all users (and programmers) to share a common view of the data<br />
resource, thus facilitating greatly the analysis of user needs.<br />
10. An organization has three diverse operating units: tractors, sewing machines, and<br />
computer chips. These units have different customers, suppliers, and production<br />
facilities. Operating data are consolidated for financial reporting only.<br />
11. An entity is anything about which the organization wishes to capture data. Entities<br />
may be physical, such as “Inventory”, “Customer”, or “Employee”. They may also be<br />
conceptual, such as “Sale” (to a customer), “Accounts Receivable”, or “Accounts<br />
Payable”.<br />
© 2008 Cengage Learning
Chapter 9 Page 341<br />
12. The XYZ company is a geographically distributed organization with several sites<br />
around the country. Users at these sites need rapid access to common data for<br />
read-only purposes.<br />
13. (1:0,1) Every occurrence (record) in a one entity (Employee), there is a possibility of<br />
zero or one occurrence in the related entity (Company Car).<br />
(1:1) Describes a situation in which each record in one entity is always associated with<br />
one (and only one) record in the associated entity. For example, a company laptop<br />
computer is assigned to only one manager, and every manager is assigned only one<br />
laptop.<br />
(1:M) An example of this situation is that each item of Inventory (entity) is supplied by<br />
one and only one Vendor (related entity), but each Vendor supplies one or many<br />
different Inventory items to the company.<br />
(M:M) A company with a policy of purchasing the same types of inventory from multiple<br />
suppliers would have a M:M association between the Vendor and Inventory entities.<br />
14. The term association pertains to the nature of the relationship between two entities.<br />
This is represented by a verb such as shipped, requests, or receives. Cardinality is<br />
the degree of association between two entities. Simply stated, cardinality describes<br />
the number of possible occurrences in one table that are associated with a single<br />
occurrence in a related table.<br />
15. A network model allows parents to have multiple children and vice versa. A separate<br />
linking file works by creating a file that contains pointer records in linked-list<br />
structure. This file contains the addresses of multiple predefined links.<br />
16. a. All occurrences at the intersection of a row and column are a single value. No<br />
multiple values (repeating groups) are allowed.<br />
b. The attribute values in any column must all be of the same class.<br />
c. Each column in a given table must be uniquely named.<br />
d. Each row in the table must be unique in at least one attribute that is considered to be<br />
the primary key.<br />
17. a. Restrict—Extracts rows that satisfy the given condition from a specified table<br />
and places these rows into a new table.<br />
b. Project—Extracts columns from a specified table and places these attributes<br />
(columns) into a new table.<br />
c. Join—Builds a new table from two tables consisting of all concatenated pairs of rows,<br />
one from each table.<br />
18. A table normalized to 3NF meets the following conditions:<br />
1. All nonkey attributes in the table are dependent on the primary key.<br />
2. All nonkey attributes are independent of the other nonkey attributes.<br />
In other words, the primary key of a table wholly and uniquely defines each attribute in<br />
the table, and none of the table attributes are defined by an attribute other than the<br />
primary key.<br />
© 2008 Cengage Learning
Chapter 9 Page 342<br />
19. The user may restrict the fields of data to view with the AS SELECT command. Further,<br />
the user may restrict the rows or records of data to be viewed with the WHERE<br />
command. The WHERE command allows the user to view only those records that have<br />
values which fall within a certain range for one or more fields of data.<br />
20. A data model is the blueprint for creating the physical database. Database designers<br />
identify system entities and prepare a model of them using a graphical<br />
representation technique called an entity relationship (ER) diagram.<br />
21. The deletion anomaly may cause records to be deleted unintentionally and may<br />
occur for some time before the problem is noticed. A deletion anomaly occurs when<br />
an item in one file is legitimately deleted. The problem occurs when this file is linked<br />
to another file, which may also have a record deleted, due to its link. If the second<br />
record should not be deleted, then an update anomaly has occurred.<br />
22. A user view is the set of data that a particular user sees. Examples of user views are<br />
computer screens for entering or viewing data, management reports, or source<br />
documents, such as an invoice.<br />
23. User views derive from underlying database tables. Simple views may be<br />
constructed from a single table, while more complex views may require several<br />
tables. Furthermore, a single table may contribute data to many different views.<br />
24. Valid entities meet the two conditions below:<br />
Condition 1. An entity must have two or more occurrences.<br />
Condition 2. An entity must contribute at least one attribute that is not<br />
provided through other entities.<br />
25. Because attributes are the logical and relevant characteristics of an entity, they are<br />
unique to it. Therefore, the same attribute should not be used to define two different<br />
entities.<br />
DISCUSSION QUESTIONS<br />
1. In the traditional data management environment, applications are developed with<br />
data and program dependency. Typically, these programs are application specific.<br />
Thus, the users of the application data tend to be proprietary about the data in “their”<br />
application and may not be amenable to sharing such data.<br />
2. If your university were to use different databases for the registrar, library, parking,<br />
food services, and computing services, then the number of forms you would have to<br />
fill out, if any of your personal data changes, would be plentiful. For example, if you<br />
were to move during the semester to a different apartment, the university should be<br />
notified. In this situation, a couple of things could happen. You could be required to<br />
go to each service individually and fill out an address form, or you could go to one<br />
central location and fill out a form that has multiple copies, which are sent to the<br />
various areas on campus for update. In any case, your address could be keyed in<br />
correctly by the registrar. You might receive some correspondence from the registrar<br />
and assume that the address correction was made. However, a keypunch error<br />
might have occurred by the library staff, and you may not receive notification that<br />
© 2008 Cengage Learning
Chapter 9 Page 343<br />
you have a library book which you forgot about past due. After the end of the<br />
semester, you may not receive your final grade report. When you call the registrar,<br />
you may find out that the library has reported that you have an overdue book and<br />
that your grades should be held until the book is returned, and the fine is paid.<br />
3. Under the database concept, the data becomes centrally stored with many different<br />
users accessing the database. However, each user should not have access to the<br />
whole database. Under the traditional data management approach, where the data<br />
are limited to a single application, the user access problem was not as much of a<br />
threat. The DBMS is a special software system that is programmed to know which<br />
data each user is authorized to access. This controlled authorization is crucial in<br />
centrally stored DBMSs.<br />
4. User views are derived database tables. A single table may contribute data to<br />
several different views On the other hand, simple views may be constructed from a<br />
single table.<br />
5. Tables that are logically related in the data model need to be physically linked. The<br />
degree of association between the tables (i.e., 1:1, 1:M, or M:M) determines how the<br />
linking occurs. The key-assignment rules for linking tables are discussed below:<br />
• Where a true 1:1 association exists between tables, either (or both) primary<br />
keys may be embedded as foreign keys in the related table.<br />
• Where a 1:M (or 1:0,M) association exists, the primary key of the 1 side is<br />
embedded in the table of the M-side.<br />
• To represent the M:M association between tables, a link table needs to be<br />
created which has a combined (composite) key consisting of the primary keys of<br />
two related tables.<br />
6. The entity relationship (ER) diagram is the graphical representation technique used<br />
to depict a data model. Each entity in a ER diagram is named in the singular noun<br />
form, such as Customer rather than Customers. The labeled line connecting two<br />
entities describes the nature of the association between them. This association is<br />
represented with a verb, such as shipped, requests, or receives. The ER diagram<br />
also represents cardinality (the degree of association between two entities). Four<br />
basic forms of cardinality are possible: zero or one (0,1), one and only one (1,1),<br />
zero or many (0,M), and one or many (1,M). These are combined to represent<br />
logical associations between entities such as 1:1, 1:0,M, and M:M.<br />
7. SQL allows users to retrieve data from many different files without the assistance of<br />
programmer professionals. Thus, if the user has access to data files and knows<br />
SQL, which is very user friendly, the user may retrieve the data instantaneously.<br />
8. The data was not centrally stored for many different applications to use in the<br />
traditional data management environment. Because it is centrally stored and shared<br />
by many users in a database environment, the need arose for an individual to care<br />
for and control these files. The database administrator is responsible for database<br />
planning, developing the data requirements and data dictionary, database design<br />
and controls, database implementation and access controls, operation and<br />
maintenance, and establishing and reviewing the standards and procedures.<br />
© 2008 Cengage Learning
Chapter 9 Page 344<br />
9. The system programmer’s program should not have access to the data, except<br />
perhaps temporarily to test the programs. The database administrator controls the<br />
access to the data. If one person has the authority to both write programs and<br />
access data, then control issues become a concern. The potential to commit fraud or<br />
embezzlement or to destroy or alter the company’s records increases.<br />
10. Neither table can donate an embedded key to the other, because both are on the<br />
“many” side. The only solution, therefore, is to create a new link table containing the<br />
key fields of both tables.<br />
11. Tables that are not normalized contain anomalies which require excessive updates<br />
to tables, prevent data from being stored properly, and may cause unintentional<br />
deletion of data. Accountants need to be familiar with normalization issues, because<br />
these anomalies threaten the integrity of the financial data of the organization.<br />
12. A database lockout prevents multiple users from accessing the same table<br />
simultaneously and making changes to data values while they are temporarily<br />
inconsistent. Lockouts force changes to be made sequentially to ensure data accuracy.<br />
13. Database concurrency controls ensure the completeness and accuracy of a<br />
distributed database at remote sites where the same beginning data balances are<br />
updated by different transactions. This is accomplished by serializing and timestamping<br />
transactions. Depending on the need for data currency, the time-stamped<br />
data will be reconciled and posted to all distributed databases.<br />
14. Database accounting systems are transaction-based rather than account-based.<br />
The focus is on capturing important details of transactions that may be lost when<br />
they are forced into the structure of traditional accounting records. The transaction<br />
tables are then to be used to reconstruct traditional accounting records, such as<br />
Accounts Receivable and Accounts Payable.<br />
15. Where a true 1:1 association exists between tables, either (or both) primary keys<br />
may be embedded as foreign keys in the related table. On the other hand, when the<br />
lower cardinality value is zero (1:0,1), a more efficient table structure can be<br />
achieved by placing the 1-side (1:) table’s primary key in the zero-or-one (:0,1) table<br />
as a foreign key. Assume that a company has 1000 employees, but only 100 of them<br />
are sales staff. Also assume that each sales person is assigned a company car.<br />
Therefore, every occurrence in the Employee entity is associated with either zero or<br />
one occurrence in the Company Car entity. If we assigned the Company Car (:0,1)<br />
side primary to the Employee (:1) table as a foreign key, then most of the foreign<br />
keys will have null (blank) values. While this approach would work, it could cause<br />
some technical problems during table searches. Correctly applying the keyassignment<br />
rule solves this problem, because all Company Car records will have an<br />
employee assigned, and no null values will occur.<br />
16. The insertion and update anomalies would create record keeping and operational<br />
problems for the firm. However, flawed databases design that prevents the insertion<br />
of records, or requires the user to perform excessive updates, would attract attention<br />
quickly. The presence of the deletion anomaly is less conspicuous, but potentially<br />
more serious from an accounting perspective. Because the deletion anomaly may go<br />
© 2008 Cengage Learning
Chapter 9 Page 345<br />
undetected, the user may be unaware of the loss of important data until it is too late.<br />
This anomaly can result in the unintentional loss of critical accounting records and<br />
the destruction of the audit trail.<br />
17. The organization’s business rules directly impact the structure of the database<br />
tables. If the database is to function properly, its designers need to understand the<br />
organization’s business rules, as well as the specific needs of individual users. For<br />
example:<br />
1. When an organization decides to purchase the same items of inventory from<br />
different suppliers, the cardinality between the Supplier and Inventory tables is M:M.<br />
2. When a the company purchases all items of a certain type from only one supplier,<br />
the cardinality between Supplier and Inventory tables is 1:M respectively.<br />
3. A policy that a separate receiving report is prepared for the receipt of goods specified<br />
on a single purchase order will result in a 1:1 cardinality between the receiving report<br />
and purchase order tables. If, however, multiple purchase orders are combined on a<br />
single receiving report, then the cardinality between these tables will be 1: M<br />
respectively.<br />
18. The partitioned approach works best for organizations that require minimal data<br />
sharing among users at remote sites. To the extent that remote users share<br />
common data, the problems associated with the centralized approach will apply. The<br />
primary user must now manage requests for data from other sites. Selecting the<br />
optimum host location for the partitions, to minimize data access problems, requires<br />
an in-depth analysis of end-user data needs.<br />
19. To achieve data currency, simultaneous access to individual data elements or<br />
records by multiple users needs to be prevented. The solution to this problem is a<br />
database lockout, which is a software control that prevents multiple simultaneous<br />
accesses to data. A deadlock occurs when multiple users seeking access to the<br />
same set of records lockout each other. As a result, the transactions of all users<br />
assume a “wait” state until the locks are removed. A deadlock is a permanent<br />
condition that must be resolved by special software that analyzes each deadlock<br />
condition to determine the best solution.<br />
20. The primary justification for a replicated database is to support read-only queries in<br />
situations involving a high degree of data sharing, but no primary user exists. With<br />
data replicated at every site, data access for query purposes is ensured, and<br />
lockouts and delays due to network traffic are minimized. A potential problem arises,<br />
however, when replicated databases need to be updated by transactions. Since<br />
each site processes only local transactions, the common data attributes that are<br />
replicated at each site will be updated by different transactions and thus, at any point<br />
in time, will have uniquely different values. System designers need to employ<br />
currency control techniques to ensure that transactions processed at different<br />
locations are accurately reflected in all the database copies.<br />
© 2008 Cengage Learning
Chapter 9 Page 346<br />
MULTIPLE CHOICES<br />
1. D<br />
2. C<br />
3. D<br />
4. E<br />
5. D<br />
6. D<br />
7. A<br />
8. C<br />
9. B<br />
10. C<br />
11. D<br />
12. C<br />
13. D<br />
14. C<br />
15. A<br />
16. D<br />
17. A<br />
18. D<br />
PROBLEMS<br />
1. August 23, 199X<br />
MEMO TO: Al Brindifi, VP Operations<br />
Carla Glasser, VP Finance<br />
James Closter, VP Marketing<br />
Julia Tinner, Controller<br />
Beth Clark, Manager of Information Systems<br />
FROM: Solutions Consultants<br />
SUBJ: Conversion of data processing systems<br />
After examining the operations of your organization and deriving a rough-cut estimate of<br />
your needs, this consulting team feels that your organization would benefit greatly from<br />
a database management system. A database management system will allow data to be<br />
shared amongst the departments, thus facilitating communication. One of the problems<br />
that has been brought repeatedly to our attention, is the need for information by user<br />
groups, which is currently kept by the organization. These user groups are having<br />
trouble gaining access to the data, because it does not reside in that user groups’<br />
application. A database management system will provide a central data source,<br />
whereby each authorized user group may gain access to the data it needs. Further, we<br />
see many inefficiencies in processing data due to data duplication by various<br />
applications. An even greater problem is that the data is oftentimes not consistent from<br />
one application to another. The DBMS will reduce data duplication and data<br />
redundancy. We propose that you begin a conversion to a DBMS. This conversion will<br />
require that a database administrator be appointed or hired. A DBMS requires that the<br />
© 2008 Cengage Learning
Chapter 9 Page 347<br />
central data store be diligently planned, managed, and maintained. The database<br />
administrator would perform these functions, as well as control user access to the data.<br />
2. a. indexed sequential or indexed random; least optimal: sequential<br />
b. indexed random or hashing; least optimal: sequential<br />
c. sequential; least optimal: indexed random<br />
d. sequential or pointer; least optimal: indexed random<br />
e. indexed random or hashing; least optimal: sequential<br />
f. indexed random or hashing; least optimal: sequential<br />
g. indexed random; least optimal: hashing<br />
3.<br />
ER Diagram for Video Store<br />
Copy DVD Supplier<br />
Customer<br />
Household<br />
Member<br />
Supplier Table<br />
Supplier ID Supplier<br />
(PK) Name<br />
Supplier/DVD Table<br />
Supplier ID DVD #<br />
(PK) (PK)<br />
DVD Table<br />
DVD #<br />
(PK)<br />
Copy Table<br />
Copy ID<br />
(PK)<br />
DVD<br />
Name<br />
DVD #<br />
(FK)<br />
Supplier<br />
Address<br />
DVD<br />
Genre<br />
Terms Balance Supplier<br />
Phone #<br />
Year of<br />
Release<br />
Cost<br />
Rental<br />
Time<br />
© 2008 Cengage Learning
Chapter 9 Page 348<br />
Customer Table<br />
Customer Name of<br />
Phone Primary<br />
#(PK) Customer<br />
Household Member Table<br />
Member # Customer<br />
(PK) Phone #<br />
(FK)<br />
Address<br />
Name of<br />
Household<br />
Member<br />
Credit<br />
Card #<br />
Age<br />
Restrictions<br />
4. Mail order catalogues are beginning to be customized based upon the preferences<br />
and purchasing patterns of the customers. If data is stored regarding the customer<br />
preferences and their buying patterns, then catalogues containing only the items<br />
which are believed to be of value to the customer may be contained in the<br />
catalogue. Printing costs and postage costs would be saved. Also, more items could<br />
be included which fit the pattern of the customer. Further, the customer does not<br />
have to weed through the catalogue to find the items that he or she likes. The<br />
technology is changing such that customized or semi-customized (for groups of<br />
people) catalogues are a reality.<br />
Listed below are some files and some fields in the files which would be necessary in<br />
addition to the traditional accounts receivable, cash receipts, vendor, and general ledger<br />
files.<br />
Customer Sales Inventory Inventory Type<br />
Master File File Master File File<br />
Customer Number Customer Number Item Number Product Type<br />
Name<br />
Sales Order Number Item Description Product Classification<br />
Address $ Amount of Items Product Type<br />
Phone Taxes Quantity on Hand<br />
Credit Card Type Freight Selling Price<br />
Credit Card Number<br />
Total Amount<br />
Credit Card Expiration<br />
Last Purchase Date<br />
Cumulative Purchase Amount<br />
Purchases in Last 12 months Sales Order Detail<br />
Purchases in Last 3 months File<br />
$ Purchases of Type A Sales Order Number<br />
$ Purchases of Type B Item Number<br />
$ Purchases of Type C Quantity<br />
$ Purchases of Type D Discount<br />
Request Type A catalogue<br />
Request Type B catalogue<br />
Request Type C catalogue<br />
Request Type D catalogue<br />
© 2008 Cengage Learning
Chapter 9 Page 349<br />
5. Lockout. The example below illustrates how two different transactions are being<br />
processed against the same AR control account within the same time frame. The<br />
individual logic steps are shown in their actual sequence of execution. If no database<br />
lockout were in place, the AR Control value of 20,000 is retrieved by both users of<br />
the system. One user is posting a payment to Sub Account 1 of $500 and the other<br />
is posting a payment to Sub Account 2 for $800.<br />
AR<br />
Control<br />
Time IPU Instruction Sub Acct 1 Sub Account 2 Account<br />
1:00:001 A Read sub acct 1 1,000<br />
1:00:001 B Read sub acct 2 3,000<br />
1:00:002 A Update sub acct 1 500<br />
1:00:002 B Update sub acct 2 2,200<br />
1:00:003 A Read control acct 20,000<br />
1:00:003 B Read control acct 20,000<br />
1:00:004 A Update control acct 19,500<br />
1:00:005 B Update control acct 19,200<br />
The update process does not reflect the second to last instruction executed. The AP<br />
Control Account should reflect payments received of $1,300, but it only $800 of<br />
payments are accounted for. Thus, a transaction is lost, and the control and subsidiary<br />
ledgers are out of balance.<br />
Deadlock. A deadlock occurs when multiple sites lock out each other. Take for<br />
example, a mail order company in which two customers are processing transactions<br />
simultaneously. Customer 1 wants to order 2 items—Item A and Item B. Customer 2 is<br />
purchasing Item B and Item A. Customer 1 informs the phone clerk that he or she<br />
wants Item A, and the record for Item A is locked until the order is complete. Meanwhile,<br />
Customer 2 orders Item B from another phone clerk who locks it. Customer 1 then<br />
requests Item B, which is locked by Customer 2’s order. The phone clerk apologizes for<br />
the delay and says the system is slow today. Customer 2 then requests Item A, which is<br />
locked by Customer 1’s order. The phone clerk helping Customer 2 apologizes for the<br />
delay and says the system is slow today. Unfortunately, neither transaction can be<br />
completed, resulting in deadlock. This condition will not be resolved unless some type of<br />
intervention occurs.<br />
6. SELECT Customer Name, Inventory Number, Item Description, Due Date<br />
FROM Customer Table, Rental Line Items Table<br />
WHERE Due Date < Today<br />
7. The best distributed approach is a replicated database.<br />
Reasoning<br />
• The users are distributed around the country and need rapid access to data. A<br />
centralized model may result in long delays because of network traffic and<br />
database lockout.<br />
© 2008 Cengage Learning
Chapter 9 Page 350<br />
• User data needs are common not unique. Since there are no identifiable primary<br />
users, partitioning the database will accomplish nothing.<br />
• Because usage is read-only, changes will not occur and database concurrency is<br />
not a problem.<br />
8. The best distributed approach is a partitioned database.<br />
Reasoning<br />
• The users are distributed around the country and need rapid access to data. A<br />
centralized model may result in long delays because of network traffic and<br />
database lockout.<br />
• User data needs are unique with identifiable primary users. There is no need to<br />
replicate the entire database.<br />
• Since users are unique, changes to the database will not cause database<br />
concurrency problem.<br />
9. The first step is to remove repeating groups. The removal of repeating groups<br />
results in the following two tables. Due Date has been removed because it is a<br />
calculated field. Student ID Number is the primary key for the Student table. Student<br />
Id Number and Book Call No. together are the primary key for the Library table.<br />
Student table is now in 3NF. Library table requires further normalization.<br />
Student Table<br />
Student ID<br />
Number<br />
Library Table<br />
Student ID<br />
Number<br />
Student First<br />
Name<br />
Student Last<br />
Name<br />
No. of Books<br />
Out<br />
Book Call No. Book Title Date Out<br />
The second step is to remove partial dependencies from Library table.<br />
Book Title is partially dependent on the Book Call No. component of the primary key.<br />
This assumes that the call number is unique to the book, and not to the event of<br />
borrowing the book. It also assumes that more than one copy of the book may exist in<br />
the library and that all copies have the same call number. Removing the partial<br />
dependency results in the tables below:<br />
Transaction Table<br />
Student ID<br />
Number<br />
Book Table<br />
Book Call No.<br />
Date Out<br />
Book Call No.<br />
Book Title<br />
Book Call No. is the primary key for the new table Book. Since no transitive<br />
dependencies exist, all three tables (Student, Transaction, and Book) are now in 3NF.<br />
© 2008 Cengage Learning
Chapter 9 Page 351<br />
10. Table Textbook<br />
ISBN # Title<br />
(PK)<br />
Publisher<br />
(FK)<br />
Table Publisher<br />
Publisher<br />
(PK)<br />
Address Phone #<br />
Table Class<br />
Course #<br />
(PK)<br />
Course<br />
Name<br />
Table Semester<br />
Term Year<br />
#(PK)<br />
Professor<br />
(FK)<br />
Semester<br />
Cost<br />
Selling<br />
Price<br />
Quantity<br />
on Hand<br />
Days Room # Term #<br />
(FK)<br />
Table Professor<br />
Employee<br />
# (PK)<br />
Name Address Phone Title<br />
11. See diagram below.<br />
PK Inventory Table FK<br />
Part # Description QOH Reorder Point EOQ Unit Cost Vendor #<br />
PK<br />
12. See diagram below.<br />
Vendor # Vendor Name Vendor<br />
Address<br />
PK<br />
Part # Description QOH Reorder<br />
Point<br />
Telephone Vendor Table<br />
EOQ Inventory Table<br />
Part # Vendor # Unit cost<br />
Vendor # Vendor Name Vendor Address Telephone<br />
Note: This is an example of a many-to-many relation between the inventory and vendor tables.<br />
The solution requires a link table, which also contains Unit Cost data. A composite key of<br />
Part # and Vendor # is needed to define the Unit Cost attribute, because there are many<br />
prices for each item carried, depending on which vendor supplies the part.<br />
© 2008 Cengage Learning
Chapter 9 Page 352<br />
13. See diagram below.<br />
Customer #<br />
Customer<br />
Name<br />
Address<br />
* Customer<br />
Total<br />
Customer<br />
Table<br />
Invoice # Date *Invoice Total Customer # Invoice Table<br />
Invoice # Part # Quantity<br />
*Extended<br />
Price<br />
Line Item Table<br />
Part<br />
Number<br />
Unit<br />
Price<br />
Inventory Table<br />
* Could be a calculated field<br />
14. Table Employee<br />
Employee #<br />
(PK)<br />
Name Address Date Hired Exemptions Marital<br />
Status<br />
Table PO<br />
PO # (PK) Date Employee # Vendor # (FK)<br />
(FK)<br />
Table PO/Item<br />
PO # (PK)<br />
Item # (PK) Quantity<br />
Table Item<br />
Item # (PK) Description On Hand Cost Price Location<br />
Table Vendor<br />
Vendor # (PK) Name Address Contact Terms Balance<br />
© 2008 Cengage Learning
Chapter 9 Page 353<br />
15.<br />
Solution to Problem 9-15<br />
Customer<br />
Table<br />
(PK) Customer Num<br />
Salesman<br />
Table<br />
(PK) Salesman Num<br />
None<br />
None<br />
Cash<br />
Receipts<br />
Table<br />
1 1 1<br />
Sales Order<br />
Table<br />
M M M<br />
Inventory<br />
Table<br />
(PK) Cash Rec Num<br />
Customer Num (FK)<br />
(PK) Invoice Num<br />
Customer Num (FK)<br />
Salesman Num (FK)<br />
Part Number (FK)<br />
M 1<br />
(PK) Part Number<br />
None<br />
M<br />
Supplier<br />
Table<br />
Link<br />
Table<br />
(PK) Vendor Num<br />
None<br />
M<br />
(PK) Part Number<br />
(PK) Vendor Num<br />
© 2008 Cengage Learning
Chapter 9 Page 354<br />
16. a. and b.<br />
Rejected Entities<br />
Payroll Clerk<br />
Reason<br />
Violates rule 1 and 2––Wording suggests only<br />
one clerk (rule 1) and no evidence of attributes<br />
unique to this entity (rule 2)<br />
Violates Rule 1––The company is a single<br />
occurrence<br />
Sagerod Manufacturing<br />
Company<br />
Cash Disbursements Clerk Violates rule 1 and 2<br />
Time Clock Machine Violates rule 1 and 2<br />
Supervisor Violates rule 1 and 2<br />
Check for the Total Payroll This is a view––Violates rule 2<br />
Paycheck This is a view––Violates rule 2<br />
Payroll Register This is a view––Violates rule 2<br />
Valid Entities<br />
Employee<br />
Paycheck Register<br />
Cash Disbursement Journal<br />
Time Card<br />
Earnings Record<br />
Problem 16, part c<br />
Data Model of Payroll System<br />
Employee<br />
Submits<br />
Time Card<br />
Receives<br />
Contains<br />
Paycheck<br />
Register<br />
Derived from<br />
Earnings<br />
Record<br />
Contains<br />
Cash<br />
Disbursement<br />
Journal<br />
© 2008 Cengage Learning
Chapter 9 Page 355<br />
17. a. and b.<br />
Rejected Entities<br />
Accounts Payable<br />
Department Clerk<br />
Safe Buy Grocery<br />
Stores<br />
Receiving Report<br />
Summary<br />
Part-Time Employees<br />
Unloading Personnel<br />
Sales<br />
Representatives<br />
Obsolescence<br />
Reports<br />
Invoice (physical)<br />
Check (physical)<br />
Payment Summary<br />
Purchase Requisition<br />
Customers<br />
Reason<br />
Violates rule 1 and 2––Wording suggests only one<br />
clerk (rule 1) and no evidence of attributes unique to<br />
this entity (rule 2)<br />
Violates Rule 1––The company is a single<br />
occurrence<br />
This is a view––It derives entirely from receiving<br />
report and thus violates rule 2<br />
Violates rule 2––Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2––Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2––Assumption: The company does not<br />
capture Sales Rep data unique to each transaction.<br />
This is a view––Derived from inventory records<br />
Violates rule 2<br />
This is a view––Used to create Invoice Record<br />
Violates rule 2<br />
This is a view––Derived from Check register<br />
records. Violates rule 2<br />
This is a view––Derived from Check register records<br />
Violates rule 2<br />
This is a view––Used to create Purchase Order<br />
Violates rule 2<br />
Not relevant to this system<br />
Valid Entities<br />
Purchase Manager<br />
Reason<br />
Assumption: all store purchase managers will use<br />
the system. This entity will consist of multiple<br />
occurrences and provide manager/store-specific<br />
data not contained in other entities.<br />
Supplier Meets conditions of Rules 1 and 2<br />
Inventory Meets conditions of Rules 1 and 2<br />
Purchase Order Meets conditions of Rules 1 and 2<br />
Receiving Report Meets conditions of Rules 1 and 2<br />
Invoice (record) Meets conditions of Rules 1 and 2<br />
Payment Obligation Meets conditions of Rules 1 and 2<br />
Check (register) Meets conditions of Rules 1 and 2<br />
© 2008 Cengage Learning
Chapter 9 Page 356<br />
Problem 9-17, part c – Data Model of Purchases Procedures<br />
Updates<br />
Inventory<br />
Contains<br />
Supplies<br />
Supplier<br />
Submits<br />
Sent To<br />
Receives<br />
Supplier Invoice<br />
Check<br />
Establishes<br />
Initiates<br />
Payment<br />
Obligation<br />
Pertains<br />
To<br />
Is Associated With<br />
Is<br />
Associated<br />
With<br />
Receiving Report<br />
Is Associated With<br />
Purchase Order<br />
© 2008 Cengage Learning
Problem 9-17, part d – Fully Attributed Data Model<br />
Chapter 9 Page 357<br />
Updates<br />
Inventory<br />
Part Number<br />
Description<br />
Quantity on Hand<br />
Reorder Point<br />
Unit Cost<br />
Contains<br />
Contains<br />
Pertains To<br />
Inven/Supplier Link<br />
Part Number<br />
Supplier Number<br />
PO Item Detail<br />
Item Number<br />
PO Number<br />
Order Quantity<br />
Rec Rept Detail<br />
Part Number<br />
Rec Rept Number<br />
Quantity Received<br />
Condition<br />
Supplier<br />
Supplier Number<br />
Supplier Name<br />
Supplier Address<br />
Supplier Tel Number<br />
Submits<br />
Sent To<br />
Receives<br />
Check<br />
Check Number<br />
Supplier Number [FK]<br />
Amount<br />
Payment Date<br />
Supplier Invoice<br />
Invoice Number<br />
Supplier Number<br />
PO Number [FK]<br />
Date<br />
Amount<br />
Contains<br />
Contains<br />
Initiates<br />
Payment Obligation<br />
Cash Disb Num<br />
Check Number [FK]<br />
Supplier Number [FK]<br />
PO Number [FK]<br />
Invoice Number [FK]<br />
Payment Due Date<br />
Amount<br />
Establishes<br />
Pertains<br />
To<br />
Receiving Report<br />
Rec Rept Number<br />
PO Number [FK]<br />
Date Received<br />
Carrier Code<br />
Bill of Lading Number<br />
Prepaid<br />
Collect<br />
Is Associated With<br />
Is Associated With<br />
Is Associated With<br />
Purchase Order<br />
PO Number<br />
Supplier Number<br />
Date of Purchase<br />
Requested Delivery Date<br />
© 2008 Cengage Learning
Chapter 9 Page 358<br />
18. Solution a. and b.<br />
Rejected Entities<br />
Accounts Payable<br />
Department Clerk<br />
Safe Buy Grocery<br />
Stores<br />
FA Receiving Report<br />
Summary<br />
Receiving Clerk<br />
Accounts Payable<br />
Manager<br />
Depreciation<br />
Schedule<br />
Invoice (physical)<br />
Check (physical)<br />
Payment Summary<br />
Purchase Requisition<br />
Store Manager<br />
Reason<br />
Violates rule 1 and 2—Wording suggests only one<br />
clerk (rule 1) and no evidence of attributes unique to<br />
this entity (rule 2)<br />
Violates Rule 1—the company is a single occurrence<br />
This is a view—It derives entirely from receiving<br />
report and thus violates rule 2<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
Assumption: This is a view—Derived from data in<br />
inventory records Violates rule 2<br />
This is a view—Used to create Invoice Record<br />
Violates rule 2<br />
This is a view—Derived from Check register records.<br />
Violates rule 2<br />
This is a view—Derived from Check register records.<br />
Violates rule 2<br />
This is a view—Used to create Purchase Order.<br />
Violates rule 2<br />
Assumption: manager/store-specific data will be<br />
contained in other entities i.e. Purchase Order<br />
Valid Entities Reason<br />
Supplier Meets conditions of Rules 1 and 2<br />
Fixed Assets Inventory Meets conditions of Rules 1 and 2<br />
Purchase Order Meets conditions of Rules 1 and 2<br />
Receiving Report Meets conditions of Rules 1 and 2<br />
Invoice (record) Meets conditions of Rules 1 and 2<br />
Payment Obligation Meets conditions of Rules 1 and 2<br />
Check (register) Meets conditions of Rules 1 and 2<br />
© 2008 Cengage Learning
Chapter 9 Page 359<br />
Updates<br />
Fixed<br />
Asset<br />
Inventory<br />
Contains<br />
Supplies<br />
Supplier<br />
Submits<br />
Sent To<br />
Receives<br />
Supplier Invoice<br />
Check<br />
Establishes<br />
Initiates<br />
Payment<br />
Obligation<br />
Pertains To<br />
Is Associated With<br />
Is<br />
Associated<br />
With<br />
Receiving Report<br />
Purchase Order<br />
© 2008 Cengage Learning
Chapter 9 Page 360<br />
FA Inventory<br />
Part Number<br />
Updates<br />
Description<br />
Quantity on<br />
Location<br />
Cost<br />
Accumulated Depr<br />
Depreciation method<br />
Contains<br />
Contains<br />
Pertains To<br />
Inven/Supplier Link<br />
Part Number<br />
Supplier Number<br />
PO Item Detail<br />
Part Number<br />
PO Number<br />
Order Quantity<br />
Rec Rept Detail<br />
Supplier<br />
Sent To<br />
Part Number<br />
Rec Rept Number<br />
Quantity Received<br />
Condition<br />
Supplier Number<br />
Supplier Name<br />
Supplier Address<br />
Supplier Tel Number<br />
Submits<br />
Check<br />
Check Number<br />
Supplier Number [FK]<br />
Amount<br />
Payment Date<br />
Receives<br />
Supplier Invoice<br />
Invoice Number<br />
Supplier Number<br />
PO Number [FK]<br />
Date<br />
Amount<br />
Contains<br />
Contains<br />
Initiates<br />
Payment<br />
Cash Disb Num<br />
Check Number [FK]<br />
Supplier Number [FK]<br />
PO Number [FK]<br />
Invoice Number [FK]<br />
Payment Due Date<br />
Amount<br />
Establishes<br />
Pertains To<br />
Receiving Report<br />
Rec Rept Number<br />
PO Number [FK]<br />
Date Received<br />
Carrier Code<br />
Bill of Lading Number<br />
Prepaid<br />
Collect<br />
Is Associated With<br />
Is Associated With<br />
Is Associated<br />
With<br />
Purchase Order<br />
PO Number<br />
Supplier Number<br />
Date of Purchase<br />
Requested Delivery Date<br />
© 2008 Cengage Learning
Chapter 9 Page 361<br />
19.<br />
a.<br />
Customer<br />
Sales Order<br />
b.<br />
Item<br />
Purchase Order<br />
c.<br />
Automobile<br />
Sales Order<br />
d.<br />
Item<br />
Customer<br />
e.<br />
Customer<br />
Movie<br />
20. Solution: a. and b.<br />
Rejected Entities<br />
Sales Representative<br />
D&F Music Club<br />
John, Billing Clerk<br />
Chris, Warehouse<br />
Clerk<br />
Sandy, AR Clerk<br />
Scott, Mailroom Clerk<br />
Customer Invoice<br />
(physical)<br />
Customer Check<br />
(physical)<br />
Reason<br />
Assumption: Sales representative specific data will<br />
be contained in customer record. Violates rule 2<br />
Violates Rule 1—the company is a single<br />
occurrence<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system<br />
This is a view—created from Customer Invoice<br />
record. Violates rule 2<br />
This is a view—Derived from Check register<br />
records. Violates rule 2<br />
© 2008 Cengage Learning
Chapter 9 Page 362<br />
Rejected Entities<br />
Remittance Advise<br />
Remittance List<br />
Laura, Cash Receipts<br />
Clerk<br />
Deposit Slip<br />
Warehouse Manager<br />
Demand Forecast<br />
Purchase Requisition<br />
Sara, Purchasing<br />
Clerk<br />
PO Blind Copy<br />
Cash Disbursement<br />
Clerk<br />
Payment Check<br />
(Physical)<br />
Packing Slip<br />
Reason<br />
This is a view—Derived from Customer Invoice<br />
record at time of billing. Violates rule 2<br />
This is a view—Used to create Cash Receipt<br />
record. Violates rule 2<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system.<br />
This is a view—Created from Cash Receipt record.<br />
Violates rule 2<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system.<br />
View derived from marketing system<br />
Assumption: This is a View derived from Inventory<br />
records.<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system.<br />
This is a view—derived from Purchase Order<br />
record. Violates rule 2<br />
Violates rule 2—Assumption: no employee specific<br />
data need to be captured by this system.<br />
This is a view—Created from Check Register<br />
record. Violates rule 2<br />
This is a view—Created from Sales Order record.<br />
Violates rule 2<br />
Valid entities<br />
Reason<br />
Customer Meets conditions of Rules 1 and 2<br />
Sales Order Meets conditions of Rules 1 and 2<br />
Sales Journal Meets conditions of Rules 1 and 2<br />
Inventory Sub Ledger Meets conditions of Rules 1 and 2<br />
Bill of Lading Meets conditions of Rules 1 and 2<br />
General Ledger Meets conditions of Rules 1 and 2<br />
Cash Receipts Journal Meets conditions of Rules 1 and 2<br />
Return Record Meets conditions of Rules 1 and 2<br />
Purchase Order Meets conditions of Rules 1 and 2<br />
Supplier Meets conditions of Rules 1 and 2<br />
Account Payable Meets conditions of Rules 1 and 2<br />
Receiving Report Meets conditions of Rules 1 and 2<br />
Supplier Invoice (record) Meets conditions of Rules 1 and 2<br />
Check (register) Meets conditions of Rules 1 and 2<br />
© 2008 Cengage Learning
Chapter 9 Page 363<br />
Updates<br />
Inventory<br />
Sub<br />
Ledger<br />
Contains<br />
General Ledger<br />
Supplies<br />
Supplier<br />
Submits<br />
Sent To<br />
Receives<br />
Supplier Invoice<br />
Check Register<br />
Establishes<br />
Initiates<br />
Accounts Payable<br />
Pertains<br />
To<br />
Is Associated With<br />
Is<br />
Associated<br />
With<br />
Receiving Report<br />
Purchase Order<br />
Is Associated With<br />
© 2008 Cengage Learning
Chapter 9 Page 364<br />
Places<br />
Pertains To<br />
Customer<br />
Sales Order<br />
Is<br />
Associated<br />
With<br />
Inventory Sub Ledger<br />
Sends<br />
Sales<br />
Journal<br />
Sends<br />
Relates<br />
To<br />
Cash Receipt<br />
(Journal)<br />
Bill of Lading<br />
General Ledger<br />
Pertains To<br />
Relates To<br />
Sales Return<br />
Relates To<br />
© 2008 Cengage Learning
Chapter 9 Page 365<br />
Updates<br />
Is Associated<br />
With<br />
General Ledger<br />
GL Account<br />
Number<br />
Acct Desc.<br />
Acct Class<br />
Beginning Bal<br />
Total Dr<br />
Total Cr<br />
Current Bal<br />
Inventory<br />
Part Number<br />
GL Account Number [FK]<br />
Description<br />
Quantity on Hand<br />
Reorder Point<br />
Unit Cost<br />
Contains<br />
Supplier<br />
Supplier Number<br />
Supplier Name<br />
Supplier Add.<br />
Supplier Tel Number<br />
Contains<br />
Submits<br />
Pertains To<br />
Inven/Supplier Link<br />
Part Number<br />
Supplier Number<br />
Sent To<br />
PO Item Detail<br />
Item Number<br />
PO Number<br />
Order Quantity<br />
Rec Rept Detail<br />
Part Number<br />
Rec Rept Number<br />
Quantity<br />
Received<br />
Condition<br />
Is<br />
Associated<br />
With<br />
Check<br />
Check Number<br />
GL Account Number [FK]<br />
Supplier Number [FK]<br />
Amount<br />
Payment Date<br />
Receives<br />
Supplier Invoice<br />
Invoice Number<br />
Supplier Number<br />
PO Number [FK]<br />
Date<br />
Amount<br />
Establishes<br />
Contains<br />
Contains<br />
Initiates<br />
Accounts Payable<br />
Cash Disb Num<br />
Check Number [FK]<br />
GL Account Num [FK]<br />
Supplier Num [FK]<br />
PO Number [FK]<br />
Invoice Num [FK]<br />
Payment Due Date<br />
Amount<br />
Pertains<br />
To<br />
Receiving Report<br />
Rec Rept Number<br />
PO Number [FK]<br />
Date Received<br />
Carrier Code<br />
Bill of Lading<br />
Number<br />
Prepaid<br />
Collect<br />
Is Associated With<br />
Is Associated With<br />
Is Associated With<br />
Purchase Order<br />
PO Number<br />
Supplier Number [FK]<br />
Date of Purchase<br />
Requested Delivery Date<br />
© 2008 Cengage Learning
Chapter 9 Page 366<br />
Sends<br />
Customer<br />
Cust Acct Num<br />
Name<br />
Address<br />
Tel num<br />
E-Mail Address<br />
Credit limit<br />
Available Credit<br />
Current Balance<br />
Last Payment Date<br />
Sends<br />
Cash Receipt<br />
(Journal)<br />
Customer Check Num<br />
Customer Account<br />
Num<br />
GL Account Number<br />
[FK]<br />
Amount<br />
Date<br />
Places<br />
Is<br />
Associated<br />
With<br />
Sales Journal<br />
Sale Trans Num<br />
Sales Order Num [FK]<br />
GL Account Number [FK]<br />
Amount<br />
Date<br />
Relates<br />
To<br />
Sales Order<br />
Sales Order Num<br />
BOL Num [FK]<br />
Cust Acct Num [FK]<br />
Order Date<br />
Ship Date<br />
Terms<br />
Contains<br />
Sales Order<br />
Details<br />
Part Number<br />
Sales Order Num<br />
Quantity<br />
Pertains<br />
To<br />
Inventory Sub<br />
Ledger<br />
Part Number<br />
GL Account Number<br />
[FK]<br />
Description<br />
Quantity on Hand<br />
Reorder Point<br />
Unit Cost<br />
Sales Return<br />
Relates To<br />
General Ledger<br />
GL Account Number<br />
Acct Description<br />
Acct Class<br />
Beginning Bal<br />
Total Dr<br />
Total Cr<br />
Current Bal<br />
Pertains To<br />
Bill of Lading<br />
BOL Num<br />
Date<br />
Carrier Code<br />
Sale Return Num<br />
Relates To<br />
Cust Acct Num [FK]<br />
GL Account Number<br />
[FK]<br />
Part Num<br />
Amount<br />
Condition<br />
Date<br />
© 2008 Cengage Learning
Chapter 9 Page 367<br />
Customer<br />
Carrier<br />
Approve<br />
Customer<br />
Returns<br />
Take<br />
Customer<br />
Order<br />
Sales Order<br />
Verify and<br />
Pick Goods<br />
BOL<br />
Open Mail<br />
Prepare<br />
Remit List<br />
Sales Journal<br />
Prepare<br />
Invoice &<br />
Record Sale<br />
Return Copy<br />
Order Data<br />
Invoice<br />
Packing Slip<br />
and BOL<br />
Return Authorization<br />
Number<br />
Request<br />
Return<br />
Sales Return<br />
Inventory<br />
Sub Ledger<br />
Return Copy<br />
Remittance Advice & Check<br />
Customer Data<br />
Sales Data<br />
Remittance List and Checks<br />
Bank<br />
Customer<br />
Record<br />
Update<br />
Customer<br />
and<br />
GL Accounts<br />
Deposit<br />
Slip<br />
Update<br />
Accounts<br />
Deposit<br />
Checks<br />
Deposit<br />
Slip<br />
General<br />
Ledger<br />
Cash Rec<br />
Journal<br />
Cash Rec<br />
Data<br />
© 2008 Cengage Learning
Chapter 9 Page 368<br />
Market<br />
Research<br />
Demand Forecast<br />
Supplier<br />
Review<br />
Records<br />
Inventory Sub<br />
Ledger<br />
Goods and<br />
Supporting<br />
Docs<br />
Purchase Req<br />
Supplier<br />
Select<br />
Supplier<br />
and<br />
Create PO<br />
Purchase<br />
Order<br />
Blind Cpy<br />
Receive<br />
Counts<br />
Inspects<br />
Check<br />
Register<br />
Purchase Order<br />
Supplier<br />
Invoice<br />
Purchase<br />
Order<br />
Reconcile<br />
and Update<br />
Accounts<br />
Receiving<br />
Report<br />
Accts Payable<br />
General<br />
Ledger<br />
Make<br />
Payment on<br />
Due Date<br />
Check<br />
Supplier<br />
Invoice<br />
© 2008 Cengage Learning