(eBook PDF) Problem Solving Cases In Microsoft

Access & Excel 16th Edition instant download

https://ebooksecure.com/product/ebook-pdf-problem-solving-cases-
in-microsoft-access-excel-16th-edition/

Download more ebook from https://ebooksecure.com

We believe these products will be a great fit for you. Click
the link to download now, or visit ebooksecure.com
to discover even more!

Problem Solving Cases In Microsoft Access & Excel 16th

Edition Ellen Monk - eBook PDF

https://ebooksecure.com/download/problem-solving-cases-in-
microsoft-access-excel-ebook-pdf/

(eBook PDF) Problem Solving Cases In Microsoft Access &

Excel 15th Edition

http://ebooksecure.com/product/ebook-pdf-problem-solving-cases-
in-microsoft-access-excel-15th-edition/

(eBook PDF) Succeeding in Business with Microsoft Excel

2013: A Problem-Solving Approach

http://ebooksecure.com/product/ebook-pdf-succeeding-in-business-
with-microsoft-excel-2013-a-problem-solving-approach/

(eBook PDF) Using Microsoft Excel and Access 2016 for

Accounting 5th

http://ebooksecure.com/product/ebook-pdf-using-microsoft-excel-
and-access-2016-for-accounting-5th/
(eBook PDF) An Introduction to Statistical Problem
Solving in Geography 3rd Edition

http://ebooksecure.com/product/ebook-pdf-an-introduction-to-
statistical-problem-solving-in-geography-3rd-edition/

Odell's Clinical Problem Solving in Dentistry 4th

Edition Avijit Banerjee - eBook PDF

https://ebooksecure.com/download/odells-clinical-problem-solving-
in-dentistry-ebook-pdf/

(eBook PDF) Problem Solving with C++ 10th Edition

http://ebooksecure.com/product/ebook-pdf-problem-solving-
with-c-10th-edition/

(eBook PDF) Problem Solving with C++ 9th Edition

http://ebooksecure.com/product/ebook-pdf-problem-solving-
with-c-9th-edition/

(eBook PDF) Business Communication A Problem-Solving

Approach

http://ebooksecure.com/product/ebook-pdf-business-communication-
a-problem-solving-approach/
P R O B L E M - S O LV I N G C A S E S I N
M I C RO S O F T ® AC C E S S ™ A N D E XC E L ®

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
P R O B L E M - S O LV I N G C A S E S I N
M I C RO S O F T ® AC C E S S ™ A N D E XC E L ®
Sixteenth Annual Edition

Ellen F. Monk
Joseph A. Brady
Emilio I. Mendelsohn

Australia • Brazil • Mexico • Singapore • United Kingdom • United States

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 This is an electronic version of the print textbook. Due to electronic rights restrictions,
some third party content may be suppressed. Editorial review has deemed that any suppressed
content does not materially affect the overall learning experience. The publisher reserves the right
to remove content from this title at any time if subsequent rights restrictions require it. For
valuable information on pricing, previous editions, changes to current editions, and alternate
formats, please visit www.cengage.com/highered to search by ISBN#, author, title, or keyword for
materials in your areas of interest.

Important Notice: Media content referenced within the product description or the product
text may not be available in the eBook version.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
Problem-Solving Cases in Microsoft® © 2020, 2017 Cengage Learning, Inc.
Access™ and Excel®, 16th Annual Edition
Unless otherwise noted, all content is © Cengage.
Ellen F. Monk, Joseph A. Brady,
WCN: 02-300
Emilio I. Mendelsohn
ALL RIGHTS RESERVED. No part of this work covered by the copyright herein
may be reproduced or distributed in any form or by any means, except as
SVP, Higher Education Product Management: ­permitted by U.S. copyright law, without the prior written permission of the
Erin Joyner copyright owner.

VP, Product Management: Mike Schenk SOURCE FOR TABLES AND OTHER ILLUSTRATIONS: Copyright © Cengage.

Product Director: Lauren Murphy All screenshots, unless otherwise noted, are used with permission from
Microsoft Corporation. Microsoft® is a registered trademark of the Microsoft
Product Manager: Jaymie Falconi Corporation.

Product Assistant: Anna Goulart The authors acknowledge www.fakenamegenerator.com, which can be used
to generate data for case scenarios.
Vice President, Marketing – Science,
Technology, & Math: Jason Sakos
For product information and technology assistance, contact us at
Senior Marketing Director: Michele McTighe Cengage Customer & Sales Support, 1-800-354-9706
or support.cengage.com.
Executive Marketing Manager: Jill Staut

Marketing Development Manager: For permission to use material from this text or product,
Samantha Best submit all requests online at www.cengage.com/permissions.

Product Specialist: Danielle Klahr

Library of Congress Control Number: 2019938234
Director, Content Creation: Juliet Steiner
ISBN: 978-0-357-13863-2
Senior Manager, Content Creation:
Patty Stephan Cengage
20 Channel Street
Content Manager: Michele Stulga Boston, MA 02210

Developmental Editor: Dan Seiter USA

Cengage is a leading provider of customized learning solutions with

Technical Editor: John Freitas
employees residing in nearly 40 different countries and sales in more
Designer: Lizz Anderson than 125 countries around the world. Find your local representative at
www.cengage.com.
Production Service/Composition:
Lumina Datamatics Ltd. Cengage products are represented in Canada by Nelson Education, Ltd.

Cover image: Peach Mango/Shutterstock.com To learn more about Cengage platforms and services, register or access
your online learning solution, or purchase materials for your course, visit
www.cengage.com.

Notice to the Reader

Publisher does not warrant or guarantee any of the products described herein or perform any independent analysis in connection with
any of the product information contained herein. Publisher does not assume, and expressly disclaims, any obligation to obtain and include
information other than that provided to it by the manufacturer. The reader is expressly warned to consider and adopt all safety precautions
that might be indicated by the activities described herein and to avoid all potential hazards. By following the instructions contained herein,
the reader willingly assumes all risks in connection with such instructions. The publisher makes no representations or warranties of any kind,
including but not limited to, the warranties of fitness for particular purpose or merchantability, nor are any such representations implied
with respect to the material set forth herein, and the publisher takes no responsibility with respect to such material. The publisher shall not
be liable for any special, consequential, or exemplary damages resulting, in whole or part, from the readers’ use of, or reliance upon, this
material.

Printed in the United States of America

Print Number: 01   Print Year: 2019

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 To Karen: Thanks for your support!

—JAB

To my problem-solving students.

—EFM

To our little bean: Although we never met you, we loved you all the same. Mom and Dad

—EIM

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 BRIEF CONTENTS

Preface ix

Pa r t 1 : Da tab as e C as e s U sing M icrosoft Access

Tutorial A
Database Design 3

Tutorial B
Microsoft Access 13

Case 1
Preliminary Case: Dog Hikes 53

Case 2
The Parks and Recreation Database 59

Case 3
The Senior Concierge Database 67

Case 4
The Fresh Fish Distributor Database 73

Case 5
The Volunteer Fire Company Database 79

Pa r t 2 : D ec is io n S u p p o r t C ases Using M icrosoft Excel Scenario

Man ag er

Tutorial C
Building a Decision Support System in Excel 89

Case 6
The Ski Resort Investment Decision 113

Case 7
The College Town Budget 121

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
viii Brief Contents

Pa r t 3 : De c is io n S u p p o r t C ases Using M icrosoft Excel Solver

Tutorial D
Building a Decision Support System Using Microsoft Excel Solver 133

Case 8
Rose Tree Regional Airline 151

Case 9
The Auto Maker Product Mix Problem 163

Pa r t 4 : I nteg ratio n C a s e s Using M icrosoft Access and Excel

Case 10
The Donation Letter Analysis 173

Case 11
San Francisco Fire Incidents 183

Case 12
San Francisco Fire Incidents: Advanced Analysis 191

Pa r t 5 : Adva n ce d S kills U sing M icrosoft Excel

Tutorial E
Guidance for Excel Cases 203

Index 219

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 P R E FAC E

For more than two decades, we have taught MIS courses at the university level. From the start, we
wanted to use good computer-based case studies for the database and decision-support portions of our
courses.
At first, we could not find a casebook that met our needs! This surprised us because we thought our
requirements were not unreasonable. First, we wanted cases that asked students to think about real-
world business situations. Second, we wanted cases that provided students with hands-on experience,
using the kind of software that they had learned to use in their computer literacy courses—and that they
would later use in business. Third, we wanted cases that would strengthen students’ ability to analyze
a problem, examine alternative solutions, and implement a solution using software. Undeterred by the
lack of casebooks, we wrote our own for Cengage.
This is the sixteenth casebook we have written for Cengage. The cases are all new, and the tutorials
have been updated using Microsoft Office 2019.
As with our prior casebooks, we include tutorials that prepare students for the cases, which are chal-
lenging but doable. The cases are organized to help students think about the logic of each case’s business
problem and then about how to use the software to solve the business problem. The cases fit well in an
undergraduate MIS course, an MBA information systems course, or a computer science course devoted
to business-oriented programming.
To date we have written nearly 200 cases. We are proud to say that all of them have tried to teach
students how to use software to help them make good business decisions. The business computing envi-
ronment continues to evolve, and our cases should follow that evolution. To stay current, students need
to learn a broader range of data analysis activities. Therefore, we have increased the range of topics cov-
ered in our casebook. This edition contains instruction and a case on the differences between handling
operational data and analytical data. We have placed greater emphasis throughout the Excel portion of
the text on the various uses of pivot tables. In the future, we intend to further increase the range of data
analysis topics we cover. We welcome feedback from instructors on this process. If there are additional
topics you want to see covered in future editions or topics that should be covered differently, let us
know! Please contact Jaymie Falconi, our product manager at Cengage.

B O O K O R G A N I Z AT I O N
The book is organized into five parts:
• Database cases using Access
• Decision support cases using the Excel Scenario Manager
• Decision support cases using Excel Solver
• Integration cases and data analysis using Access and Excel
• Advanced Excel skills
Part 1 begins with two tutorials that prepare students for the Access case studies. Parts 2 and 3 each
begin with a tutorial that prepares students for the Excel case studies. All four tutorials provide students
with practice in using the software’s features—the kind of support that other books about Access and
Excel do not provide. Part 4 challenges students to use both Access and Excel to find a solution to a
business problem. Part 5 is a tutorial about advanced skills students might need to complete some of the
Excel cases. The next sections explore these parts of the book in more depth.

Part 1: Database Cases Using Microsoft Access

This section begins with two tutorials and then presents five case studies.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
x Preface

Tutorial A: Database Design

This tutorial helps students understand how to set up tables to create a database without requiring
­students to learn formal analysis and design methods, such as data normalization.

Tutorial B: Microsoft Access

The second tutorial teaches students the more advanced features of Access queries and reports—­
features that students will need to know to complete the cases.

Cases 1–5
Five database cases follow Tutorials A and B. The students must use the Access database in each case
to create forms, queries, and reports that help management. The first case is an easier “warm-up” case.
The next four cases require more effort to design the database and implement the results.

Part 2: Decision Support Cases Using Microsoft Excel Scenario Manager

This section has one tutorial and two decision support cases that require the use of the Excel Scenario
Manager.

Tutorial C: Building a Decision Support System in Excel

This section begins with a tutorial that uses Excel to explain decision support and fundamental c­ oncepts
of spreadsheet design. The case emphasizes the use of Scenario Manager to organize the output of
­multiple “what-if” scenarios.

Cases 6–7
Students can complete these two cases with Scenario Manager. In each case, students must use Excel
to model two or more solutions to a problem. Students then use the model outputs to identify and
­document the preferred solution in a memo.

Part 3: Decision Support Cases Using ­Microsoft Excel Solver

This section has one tutorial and two decision support cases that require the use of Excel Solver.

Tutorial D: Building a Decision Support System Using Microsoft Excel Solver

This section begins with a tutorial for using Excel Solver, a powerful decision support tool for solving
optimization problems.

Cases 8–9
Students use the Excel Solver tool in each case to analyze alternatives and identify and document the
preferred solution.

Part 4: Integration Cases Using Microsoft Access and Excel

Cases 10–12
These cases integrate Access and Excel. In Case 10, students will analyze data using Access queries, an
Excel table, and an Excel pivot table. Cases 11 and 12 show students how to share data between Access
and Excel to solve problems and to use the fundamentals of data analysis. For example, Case 12 illus-
trates the basic differences between operational and analytical data and how to minimize operational
impacts during data analysis.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Preface xi

Part 5: Advanced Skills Using Microsoft Excel

This part contains one tutorial that focuses on using advanced techniques in Excel.

Tutorial E: Guidance for Excel Cases

Some cases may require the use of Excel techniques that are not discussed in other tutorials or cases
in this casebook. For example, techniques for using tables and pivot tables are explained in Tutorial E
rather than in the cases themselves.

Note that previous editions of the book included a Tutorial F for guidance on giving an oral presentation.
This tutorial is now available at the Cengage Web site. To access the tutorial, see “Using the Cases and
Tutorials” below.

INDIVIDUAL CASE DESIGN

The format of the cases uses the following template:
• Each case begins with a Preview and an overview of the tasks.
• The next section, Preparation, tells students what they need to do or know to complete the case
successfully. Again, the tutorials also prepare students for the cases.
• The third section, Background, provides the business context that frames the case. The back-
ground of each case models situations that require the kinds of thinking and analysis that stu-
dents will need in the business world.
• The Assignment sections are generally organized to help students develop their analyses.
• The last section, Deliverables, lists the finished materials that students must hand in: printouts,
a memorandum, and files. The list is similar to the deliverables that a business manager might
demand.

USING THE CASES AND TUTORIALS

We have successfully used cases like these in our undergraduate MIS courses. We usually begin the
semester with Access database instruction. We assign the Access database tutorials and then a case to
each student. Then, to teach students how to use the Excel decision support system, we do the same
thing: We assign a tutorial and then a case.
Some instructors have asked for access to extra cases, especially in the second semester of a school
year. For example, they assigned the integration case in the fall, and they need another one for the
spring. To meet this need, we have set up an online “Hall of Fame” that features some of our favorite
cases from prior editions. These password-protected cases are available to instructors on the Instructor
Companion Site for this text. Go to www.cengage.com to log in to your instructor account and search
for this textbook by title, author, or ISBN. Note that the cases are in Microsoft Office 2016 format.

T E C H N I CA L I N F O R M AT I O N
The cases in this textbook were written using Microsoft Office 2019, and the textbook was tested
for quality assurance using the Windows 10 operating system, Microsoft Access 2019, and Microsoft
Excel 2019.

DATA F I L E S A N D S O L U T I O N F I L E S
We have created “starter” data files as needed for some of the Excel cases, so students need not spend
time typing in the spreadsheet skeleton. Other cases ask students to load Access starter files. All of these
files are on the Instructor and Student Companion Sites for this text. To access the Instructor or Student
Companion Site, go to www.cengage.com, log in to your account, and search for this textbook by title,
author, or ISBN. You are granted a license to copy the data files to any computer or computer network
used by people who have purchased this textbook.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
xii Preface

Solutions to the material in the text are available to instructors on the Instructor Companion Site
for this text at www.cengage.com. Search for this textbook by title, author, or ISBN. The solutions are
password protected.

ACKNOWLEDGMENTS
We would like to give many thanks to the team at Cengage, including our product manager, ­Jaymie ­Falconi;
our developmental editor, Dan Seiter; our technical editor, John Freitas; and our content manager,
Michele Stulga. As always, we acknowledge our students’ diligent work.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 PART 1
DATABASE CASES
USING MICROSOFT ACCESS

TUTORIAL A
Database Design, 3

TUTORIAL B
Microsoft Access, 13

CASE 1
Preliminary Case: Dog Hikes, 53

CASE 2
The Parks and Recreation Database, 59

CASE 3
The Senior Concierge Database, 67

CASE 4
The Fresh Fish Distributor Database, 73

CASE 5
The Volunteer Fire Company Database, 79

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
TUTORIAL A
DATABASE DESIGN
This tutorial has three sections. The first section briefly reviews basic database terminology. The second section
teaches database design. The third section features a database design problem for practice.

REVIEW OF TERMINOLOGY
You will begin by reviewing some basic terms that will be used throughout this textbook. In Access, a database
is a group of related objects that are saved in one file. An Access object can be a table, form, query, or report.
You can identify an Access database file by its suffix, .accdb.
A table consists of data that is arrayed in rows and columns. A row of data is called a record. A column
of data is called a field. Thus, a record is a set of related fields. The fields in a table should be related to one
another in some way. For example, a company might want to keep its employee data together by creating a
database table called Employee. That table would contain data fields about employees, such as their names
and addresses. It would not have data fields about the company’s customers; that data would go in a Customer
table.
A field’s values have a data type that is declared when the table is defined. Thus, when data is entered
into the database, the software knows how to interpret each entry. Data types in Access include the following:
• Text for words
• Integer for whole numbers
• Double for numbers that have a decimal value
• Currency for numbers that represent dollars and cents
• Yes/No for variables that have only two values (such as 1/0, on/off, yes/no, and true/false)
• Date/Time for variables that are dates or times
Each database table should have a primary key field—a field in which each record has a unique value. For
example, in an Employee table, a field called Employee Identification Number (EIN) could serve as a primary
key. (This assumes that each employee is given a number when hired and that these numbers are not reused
later.) Sometimes, a table does not have a single field whose values are all different. In that case, two or more
fields are combined into a compound primary key. The combination of the fields’ values is unique.
Database tables should be logically related to one another. For example, suppose a company has an
Employee table with fields for EIN, Name, Address, and Telephone Number. For payroll purposes, the com-
pany has an Hours Worked table with a field that summarizes Labor Hours for individual employees. The rela-
tionship between the Employee table and Hours Worked table needs to be established in the database, so you
can determine the number of hours worked by any employee. To create this relationship, you include the pri-
mary key field from the Employee table (EIN) as a field in the Hours Worked table. In the Hours Worked table,
the EIN field is then called a foreign key because it’s from a “foreign” table.
In Access, data can be entered directly into a table, or it can be entered into a form, which then inserts
the data into a table. A form is a database object that is created from an existing table to make the process of
entering data more user-friendly.
A query is the database equivalent of a question that is posed about data in a table (or tables). For
­example, suppose a manager wants to know the names of employees who have worked for the company for
more than five years. A query could be designed to search the Employee table for the information. The query
would be run, and its output would answer the question.
Queries can be designed to search multiple tables at a time. For this to work, the tables must be
­connected by a join operation, which links tables on the values in a field that they have in common.
The ­common field acts as a “hinge” for the joined tables; when the query is run, the query generator treats
the joined tables as one large table.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
4 Tutorial A

In Access, queries that answer a question are called select queries because they select relevant data
from the database records. Queries can also be designed to change data in records, add a record to the end
of a table, or delete entire records from a table. These queries are called update, append, and delete queries,
respectively.
Access has a report generator that can be used to format a table’s data or a query’s output.

DATABASE DESIGN
Designing a database involves determining which tables belong in the database and then creating the fields
that belong in each table. This section begins with an introduction to key database design concepts, then dis-
cusses design rules you should use when building a database. First, the following key concepts are defined:
• Entities
• Relationships
• Attributes

Database Design Concepts

Computer scientists have highly formalized ways of documenting a database’s logic. Learning their notations
and mechanics can be time-consuming and difficult. In fact, doing so usually takes a good portion of a systems
analysis and design course. This tutorial will teach you database design by emphasizing practical business
knowledge; the approach should enable you to design serviceable databases quickly. Your instructor may add
more formal techniques.
A database models the logic of an organization’s operation, so your first task is to understand the opera-
tion. You can talk to managers and workers, make your own observations, and look at business documents,
such as sales records. Your goal is to identify the business’s “entities” (sometimes called objects). An entity is
a thing or event that the database will contain. Every entity has characteristics, called attributes, and one or
more relationships to other entities. Let’s take a closer look.

Entities
As previously mentioned, an entity is a tangible thing or an event. The reason for identifying entities is that
an entity eventually becomes a table in the database. Entities that are things are easy to identify. For exam-
ple, consider a car rental agency. The database for the agency would probably need to contain the names
of vehicles and the names of customers who rent them, so you would have one entity named Vehicles and
another named Customer.
In contrast, entities that are events can be more difficult to identify, probably because they are more con-
ceptual. However, events are real, and they are important. In the rental agency example, one event would be
Vehicle Rental and another event would be Hours Worked by employees.
In general, your analysis of an organization’s operations is made easier when you realize that organiza-
tions usually have physical entities such as these:
• Employees
• Customers
• Inventory (products or services)
• Suppliers
Thus, the database for most organizations would have a table for each of these entities. Your analysis also
can be made easier by knowing that organizations engage in transactions internally (within the company) and
externally (with the outside world). Such transactions are explained in an introductory accounting course, but
most people understand them from events that occur in daily life. Consider the following examples:
• Organizations generate revenue from sales or interest earned. Revenue-generating transactions
include event entities called Sales and Interest Earned.
• Organizations incur expenses from paying hourly employees and purchasing materials from sup-
pliers. Hours Worked and Purchases are event entities in the databases of most organizations.
Thus, identifying entities is a matter of observing what happens in an organization. Your powers of obser-
vation are aided by knowing what entities exist in the databases of most organizations.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Database Design 5

Relationships
As an analyst building a database, you should consider the relationship of each entity to the other entities you
have identified. For example, a college database might contain entities for Student, Course, and Section to
contain data about each. A relationship between Student and Section could be expressed as “Students enroll
in sections.”
An analyst also must consider the cardinality of any relationship. Cardinality can be one-to-one, one-to-
many, or many-to-many:
• In a one-to-one relationship, one instance of the first entity is related to just one instance of the
second entity.
• In a one-to-many relationship, one instance of the first entity is related to many instances of the
second entity, but each instance of the second entity is related to only one instance of the first.
• In a many-to-many relationship, one instance of the first entity is related to many instances of
the second entity, and one instance of the second entity is related to many instances of the first.
For a more concrete understanding of cardinality, consider again the college database with the Student,
Course, and Section entities. The university catalog shows that a course such as Accounting 101 can have
more than one section: 01, 02, 03, 04, and so on. Thus, you can observe the following relationships:
• The relationship between the entities Course and Section is one-to-many. Each course has many
sections, but each section is associated with just one course.
• The relationship between Student and Section is many-to-many. Each student can be in more
than one section, because each student can take more than one course. Also, each section has
more than one student.
Thinking about relationships and their cardinalities may seem tedious to you. However, as you work
through the cases in this text, you will see that this type of analysis can be valuable in designing databases. In
the case of many-to-many relationships, you should determine the tables a given database needs; in the case
of one-to-many relationships, you should decide which fields the tables need to share.

Attributes
An attribute is a characteristic of an entity. You identify attributes of an entity because attributes
become a table’s fields. If an entity can be thought of as a noun, an attribute can be considered an
­adjective that describes the noun. Continuing with the college database example, consider the Student
entity. Students have names, so Last Name would be an attribute of the Student entity and therefore
a field in the Student table. First Name would be another attribute, as well as Address, Phone Number,
and other descriptive fields.
Sometimes, it can be difficult to tell the difference between an attribute and an entity, but one good way
is to ask whether more than one attribute is possible for each entity. If more than one instance is possible,
but you do not know the number in advance, you are working with an entity. For example, assume that a
student could have a maximum of two addresses—one for home and one for college. You could specify attrib-
utes Address 1 and Address 2. Next, consider that you might not know the number of student addresses in
advance, meaning that all addresses have to be recorded. In that case, you would not know how many fields
to set aside in the Student table for addresses. Therefore, you would need a separate Student Addresses table
(entity) that would show any number of addresses for a given student.

Database Design Rules

As described previously, your first task in database design is to understand the logic of the business situation.
Once you understand this logic, you are ready to build the database. To create a context for learning about
database design, look at a hypothetical business operation and its database needs.

Example: The Talent Agency

Suppose you have been asked to build a database for a talent agency that books musical bands into nightclubs.
The agent needs a database to keep track of the agency’s transactions and to answer day-to-day questions. For
example, a club manager often wants to know which bands are available on a certain date at a certain time, or

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
6 Tutorial A

wants to know the agent’s fee for a certain band. The agent may want to see a list of all band members and the
instrument each person plays, or a list of all bands that have three members.
Suppose that you have talked to the agent and have observed the agency’s business operation. You con-
clude that your database needs to reflect the following facts:
1. A booking is an event in which a certain band plays in a particular club on a particular date,
starting and ending at certain times and performing for a specific fee. A band can play more than
once a day. The Heartbreakers, for example, could play at the East End Cafe in the afternoon and
then at the West End Cafe on the same night. For each booking, the club pays the talent agent.
The agent keeps a 5 percent fee and then gives the remainder of the payment to the band.
2. Each band has at least two members and an unlimited maximum number of members. The agent
notes a telephone number of just one band member, which is used as the band’s contact number.
No two bands have the same name or telephone number.
3. Band member names are not unique. For example, two bands could each have a member named
Sally Smith.
4. The agent keeps track of just one instrument that each band member plays. For the purpose of
this database, “vocals” are considered an instrument.
5. Each band has a desired fee. For example, the Lightmetal band might want $700 per booking and
would expect the agent to try to get at least that amount.
6. Each nightclub has a name, an address, and a contact person. The contact person has a tele-
phone number that the agent uses to call the club. No two clubs have the same name, contact
person, or telephone number. Each club has a target fee. The contact person will try to get the
agent to accept that fee for a band’s appearance.
7. Some clubs feed the band members for free; others do not.
Before continuing with this tutorial, you might try to design the agency’s database on your own. Ask your-
self: What are the entities? Recall that business databases usually have Customer, Employee, and Inventory
entities, as well as an entity for the event that generates revenue transactions. Each entity becomes a table in
the database. What are the relationships among the entities? For each entity, what are its attributes? For each
table, what is the primary key?

Six Database Design Rules

Assume that you have gathered information about the business situation in the talent agency example. Now
you want to identify the tables required for the database and the fields needed in each table. Observe the fol-
lowing six rules:
Rule 1: You do not need a table for the business. The database represents the entire business. Thus, in the
example, Agent and Agency are not entities.
Rule 2: Identify the entities in the business description. Look for typical things and events that will become
tables in the database. In the talent agency example, you should be able to observe the following entities:
• Things: The product (inventory for sale) is Band. The customer is Club.
• Events: The revenue-generating transaction is Bookings.
You might ask yourself: Is there an Employee entity? Isn’t Instrument an entity? Those issues will be
­discussed as the rules are explained.
Rule 3: Look for relationships among the entities. Look for one-to-many relationships between entities.
The relationship between those entities must be established in the tables, using a foreign key. For details, see
the following discussion in Rule 4 about the relationship between Band and Band Member.
Look for many-to-many relationships between entities. Each of these relationships requires a third entity
that associates the two entities in the relationship. Recall the many-to-many relationship from the college
database scenario that involved Student and Section entities. To display the enrollment of specific students
in specific sections, a third table would be required. The mechanics of creating such a table are described in
Rule 4 during the discussion of the relationship between Band and Club.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Database Design 7

Rule 4: Look for attributes of each entity and designate a primary key. As previously mentioned, you
should think of the entities in your database as nouns. You should then create a list of adjectives that describe
those nouns. These adjectives are the attributes that will become the table’s fields. After you have identified
fields for each table, you should check to see whether a field has unique values. If such a field exists, designate
it as the primary key field; otherwise, designate a compound primary key.
In the talent agency example, the attributes, or fields, of the Band entity are Band Name, Band Phone
Number, and Desired Fee, as shown in Figure A-1. Assume that no two bands have the same name, so the pri-
mary key field can be Band Name. The data type of each field is shown.

BAND

Field Name Data Type

Band Name (primary key) Text

Band Phone Number Text

Desired Fee Currency

FIGURE A-1 The Band table and its fields

Two Band records are shown in Figure A-2.

Band Name (primary key) Band Phone Number Desired Fee

Heartbreakers 981 831 1765 $800

Lightmetal 981 831 2000 $700

FIGURE A-2 Records in the Band table

If two bands might have the same name, Band Name would not be a good primary key, so a different
unique identifier would be needed. Such situations are common. Most businesses have many types of inven-
tory, and duplicate names are possible. The typical solution is to assign a number to each product to use as the
primary key field. A college could have more than one faculty member with the same name, so each faculty
member would be assigned an EIN. Similarly, banks assign a personal identification number (PIN) for each
depositor. Each automobile produced by a car manufacturer gets a unique vehicle identification number (VIN).
Most businesses assign a number to each sale, called an invoice number. (The next time you go to a grocery
store, note the number on your receipt. It will be different from the number on the next customer’s receipt.)
At this point, you might be wondering why Band Member would not be an attribute of Band. The answer
is that, although you must record each band member, you do not know in advance how many members are in
each band. Therefore, you do not know how many fields to allocate to the Band table for members. (Another
way to think about band members is that they are the agency’s employees, in effect. Databases for organiza-
tions usually have an Employee entity.) You should create a Band Member table with the attributes Member
ID Number, Member Name, Band Name, Instrument, and Phone. A Member ID Number field is needed because
member names may not be unique. The table and its fields are shown in Figure A-3.

BAND MEMBER

Field Name Data Type

Member ID Number (primary key) Text

Member Name Text

Band Name (foreign key) Text

Instrument Text

Phone Text

FIGURE A-3 The Band Member table and its fields

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
8 Tutorial A

Note in Figure A-3 that the phone number is classified as a Text data type because the field values will
not be used in an arithmetic computation. The benefit is that Text data type values take up fewer bytes than
Numerical or Currency data type values; therefore, the file uses less storage space. You should also use the
Text data type for number values such as zip codes.
Five records in the Band Member table are shown in Figure A-4.

Member ID Number (primary key) Member Name Band Name Instrument Phone

0001 Jamal Marshall Heartbreakers Guitar 981 444 1111

0002 Chantal Marshall Heartbreakers Vocals 981 444 1234

0003 Tirsa Abboud Heartbreakers Keyboard 981 555 1199

0004 Diego Flores Lightmetal Sax 981 888 1654

0005 Sue Hoopes Lightmetal Piano 981 888 1765

FIGURE A-4 Records in the Band Member table

You can include Instrument as a field in the Band Member table because the agent records only one
instrument for each band member. Thus, you can use the instrument as a way to describe a band member,
much like the phone number is part of the description. Phone could not be the primary key because two
members might share a telephone and because members might change their numbers, making database
administration more difficult.
You might ask why Band Name is included in the Band Member table. The common-sense reason is that
you did not include the Member Name in the Band table. You must relate bands and members somewhere,
and the Band Member table is the place to do it.
To think about this relationship in another way, consider the cardinality of the relationship between Band
and Band Member. It is a one-to-many relationship: one band has many members, but each member in the
database plays in just one band. You establish such a relationship in the database by using the primary key
field of one table as a foreign key in the other table. In Band Member, the foreign key Band Name is used to
establish the relationship between the member and his or her band.
The attributes of the Club entity are Club Name, Address, Contact Name, Club Phone Number, Preferred
Fee, and Feed Band?. The Club table can define the Club entity, as shown in Figure A-5.

CLUB

Field Name Data Type

Club Name (primary key) Text

Address Text

Contact Name Text

Club Phone Number Text

Preferred Fee Currency

Feed Band? Yes/No

FIGURE A-5 The Club table and its fields

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Database Design 9

Two records in the Club table are shown in Figure A-6.

Club Name (primary key) Address Contact Name Club Phone Number Preferred Fee Feed Band?

East End 1 Duce St. Neev Kalb 981 444 8877 $600 Yes

West End 99 Duce St. Vera Kaan 981 555 0011 $650 No

FIGURE A-6 Records in the Club table

You might wonder why Bands Booked into Club (or a similar name) is not an attribute of the Club table.
There are two reasons. First, you do not know in advance how many bookings a club will have, so the value
cannot be an attribute. Second, Bookings is the agency’s revenue-generating transaction, an event entity, and
you need a table for that business transaction. Consider the booking transaction next.
You know that the talent agent books a certain band into a certain club for a specific fee on a certain date,
starting and ending at a specific time. From that information, you can see that the attributes of the Bookings
entity are Band Name, Club Name, Booking Date, Start Time, End Time, and Fee. The Bookings table and its
fields are shown in Figure A-7.

BOOKINGS

Field Name Data Type

Band Name (foreign key) Text

Club Name (foreign key) Text

Booking Date Date/Time

Start Time Date/Time

End Time Date/Time

Fee Currency

FIGURE A-7 The Bookings table and its fields—and no designation of a primary key

Some records in the Bookings table are shown in Figure A-8.

Band Name Club Name Booking Date Start Time End Time Fee

Heartbreakers East End 11/21/20 21:30 23:30 $800

Heartbreakers East End 11/22/20 21:00 23:30 $750

Heartbreakers West End 11/28/20 19:00 21:00 $500

Lightmetal East End 11/21/20 18:00 20:00 $700

Lightmetal West End 11/22/20 19:00 21:00 $750

FIGURE A-8 Records in the Bookings table

Note that no single field is guaranteed to have unique values, because each band is likely to be booked
many times and each club might be used many times. Furthermore, each date and time can appear more than
once. Thus, no one field can be the primary key.
If a table does not have a single primary key field, you can make a compound primary key whose field
values will be unique when taken together. Because a band can be in only one place at a time, one possible
solution is to create a compound key from the Band Name, Booking Date, and Start Time fields. An alter-
native solution is to create a compound primary key from the Club Name, Booking Date, and Start Time
fields.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
10 Tutorial A

If you don’t want a compound key, you could create a field called Booking Number. Each booking would
then have its own unique number, similar to an invoice number.
You can also think about this event entity in a different way. Over time, a band plays in many clubs,
and each club hires many bands. Thus, Band and Club have a many-to-many relationship, which signals
the need for a table between the two entities. A Bookings table would associate the Band and Club tables.
You implement an associative table by including the primary keys from the two tables that are associ-
ated. In this case, the primary keys from the Band and Club tables are included as foreign keys in the
Bookings table.
Rule 5: Avoid data redundancy. You should not include extra (redundant) fields in a table. Redundant fields
take up extra disk space and lead to data entry errors because the same value must be entered in multiple
tables, increasing the chance of a keystroke error. In large databases, keeping track of multiple instances of
the same data is nearly impossible, so contradictory data entries become a problem.
Consider this example: Why wouldn’t Club Phone Number be included in the Bookings table as a field?
After all, the agent might have to call about a last-minute booking change and could quickly look up the num-
ber in the Bookings table. Assume that the Bookings table includes Booking Number as the primary key and
Club Phone Number as a field. Figure A-9 shows the Bookings table with the additional field.

BOOKINGS

Field Name Data Type

Booking Number (primary key) Text

Band Name (foreign key) Text

Club Name (foreign key) Text

Club Phone Number Text

Booking Date Date/Time

Start Time Date/Time

End Time Date/Time

Fee Currency

FIGURE A-9 The Bookings table with an unnecessary field—Club Phone Number

The fields Booking Date, Start Time, End Time, and Fee logically depend on the Booking Number primary
key—they help define the booking. Band Name and Club Name are foreign keys and are needed to establish
the relationship between the Band, Club, and Bookings tables. But what about Club Phone Number? It is not
defined by the Booking Number. It is defined by Club Name—in other words, it is a function of the club, not
of the booking. Thus, the Club Phone Number field does not belong in the Bookings table. It is already in the
Club table.
Perhaps you can see the practical data-entry problem of including Club Phone Number in Bookings. Sup-
pose a club changed its contact phone number. The agent could easily change the number one time, in the
Club table. However, the agent would need to remember which other tables contained the field and change
the values there too. In a small database, this task might not be difficult, but in larger databases, having
redundant fields in many tables makes such maintenance difficult, which means that redundant data is often
incorrect.
You might object by saying, “What about all of those foreign keys? Aren’t they redundant?” In a sense,
they are. But they are needed to establish the one-to-many relationship between one entity and another, as
discussed previously.
Rule 6: Do not include a field if it can be calculated from other fields. A calculated field is made using the
query generator. Thus, the agent’s fee is not included in the Bookings table because it can be calculated by
query (here, 5 percent multiplied by the booking fee).

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Database Design 11

The Talent Agency Tables in Microsoft Access

The previous sections and figures describe the talent agency database tables, but the relationships between
the tables might be more clear in a graphical representation, which you can create in Microsoft Access (see
Figure A-10).

FIGURE A-10 Graphical view of talent agency tables

In Tutorial B, you will learn how to define a table in Access—in other words, you will input the fields and
their data types and designate the table’s primary key. Tutorial B also explains how to query tables graphically
in Access.
Figure A-10 shows the talent agency’s tables as they would be used in the Access query generator. The
relationships between tables are indicated by the links between the tables. For example, the Band Name field
is the primary key in the Band table and a foreign key in the Band Member table. The two tables are linked by
a common field to demonstrate that a band member is partially described by the name of a band. In a similar
way, a club’s name partially describes Bookings, and the two tables can be linked by a common field, Club
Name.

PRACTICE DATABASE DESIGN PROBLEM

Imagine that your town library wants to keep track of its business in a database, and that you have been called
in to build the database. You talk to the town librarian, review the old paper-based records, and watch people
use the library for a few days. You learn the following about the library:
1. Any resident of the town can get a library card simply by asking for one. The library considers
each cardholder a member of the library.
2. The librarian wants to be able to contact members by telephone and by email. She calls mem-
bers when books are overdue or when requested materials become available. She likes to email
a thank-you note to each patron on his or her anniversary of becoming a member of the library.
Without a database, contacting members efficiently can be difficult; for example, multiple mem-
bers can have the same name. Also, a parent and a child might have the same first and last name,
live at the same address, and share a phone.
3. The librarian tries to keep track of each member’s reading interests. When new books come in,
the librarian alerts members whose interests match those books. For example, long-time member
Sue Doaks is interested in reading Western novels, growing orchids, and baking bread. There must
be some way to match her interests with available books. One complication is that, although the
librarian wants to track all of a member’s reading interests, she wants to classify each book as
being in just one category of interest. For example, the classic gardening book Orchids of France
would be classified as a book about orchids or a book about France, but not both.

Copyright 2020 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
 Another Random Document on
Scribd Without Any Related Topics
 Genus Proechimys J. A. Allen
Genotype.—Echimys trinitatis Allen and Chapman, by original
designation.
Proechimys Allen and Chapman, 26 December 1899, Bull. Amer. Mus. Nat. Hist.,
12(20):264, orig. description; Tate, 1935, Bull. Amer. Mus. Nat. Hist., 68(5):398;
Ellerman, 1940, The families and genera of living rodents, Brit. Mus. (Nat. Hist.),
1:115.

General characters.—Muriform echimyids of medium size; pelage with flattened

and lanceolate and sometimes clavate aristiforms, varying greatly in width and
distributed over most of the dorsal surface from shoulders to hips or base of tail;
setiforms also flattened, evenly distributed throughout; entire ventral surface and
inner sides of legs white or, rarely, invaded by some buffy color; tail shorter than,
equal to, or slightly longer than, head and body, bicolored and with a few bristles
between scales, sometimes heavily penicillated; feet long and narrow; pollex
rudimentary; hallux shorter than fifth toe; ears wide and long; mammae 2-1=6.

Skull.—Generally elongate and strongly built, with supraorbital ridges well

developed, frequently extending across parietals toward occipital region;
zygomatic arches variable in depth, always with postorbital process; infraorbital
foramen with or without lower groove for transmission of nerve; incisive foramen
usually large; vomerine sheath complete or incomplete; mesopterygoid fossa
extending forward at least to plane of third molars; bullae large; angular process
of mandible turned upward.
 Figs. 18-21. Occlusal views of the upper left and
lower right molariform teeth of the two
subgenera of the genus Proechimys. Anterior end
of the tooth row at the top of drawing. All × 6.
Figs. 18-19. Proechimys (Proechimys) goeldii
steerei, sex ?, USNM no. 105537, "Hyutanaham."
Upper teeth at left (fig. 18).
Figs. 20-21. Proechimys (Trinomys) dimidiatus,
male, MN no. 6256, Pedra Branca.

Teeth.—Incisors opisthodont, orthodont or proodont, not grooved; upper

molariform teeth with a main internal fold and one to five external counterfolds
which usually appear as enamel islands in worn teeth, these counterfolds barely
implicating the lateral wall; lower molariform teeth with folds as in the upper
molariform teeth except that they are reversed and the number of internal
counterfolds is usually fewer in the molars.
 Artificial Key to the Subgenera and
Species
1. (a) Tail less than 90 per cent of head and body;
aristiforms not evident on outer thighs and rump; skull
with ridges across parietals; size of upper cheekteeth
increasing from P4 to M2; main fold small.
subgenus 2
Proechimys,
(b) Tail 90 per cent or more of head and body; aristiforms
evident on outer thighs and rump; skull with no ridges
across parietals; size of upper cheekteeth decreasing
from P4 to M3; main fold large.
subgenus Trinomys, 5
2. (a) One or more upper molars with four counterfolds, 3
(b) Upper molars with no more than three counterfolds, 4
3. (a) Aristiforms wide (more than 0.7 mm).
P. semispinosus, p. 342
(b) Aristiforms narrow (less than 0.7 mm).
P. goeldii, p. 338
4. (a) Aristiforms wide (0.9 mm or more), or narrow (0.6 to
0.7 mm) but then with only two counterfolds in each
lower molar.
P. guyannensis, p. 355
(b) Aristiforms narrow (0.5 to 0.65 mm) but with one or
more lower molars having three counterfold.
P. longicaudatus, p. 346
5. (a) Aristiforms narrow (0.5 mm) and limber; no
differentiated light-colored aristiforms on outer thighs
and rump; incisive foramen short and widest
posteriorly.
P. dimidiatus, p. 371
(b) Aristiforms 0.6 mm or more and stiff; differentiated
light-colored aristiforms on outer thighs and rump;
incisive foramen elongated and constricted posteriorly. 6
6. (a) Skull large, more than 50 mm in total length, incisors
opisthodont.
P. iheringi, p. 373
(b) Skull small, less than 49 mm in total length, incisors
orthodont or proodont. 7
7. (a) No clavate aristiforms, tail with white tip,
P. setosus, p. 384
(b) Clavate aristiforms among the ordinary ones, tail
without white tip,
P. albispinus, p. 388
Fig. 22. Map showing the distribution of the two subgenera of the genus
Proechimys.
Fig. 23. Map showing the geographic ranges of four species of the genus
Proechimys.
Fig. 24. Map showing the geographic ranges of four species of the genus
Proechimys.
 Subgenus Proechimys J. A. Allen
General characters.—Pelage with lanceolate aristiforms limited to an area on
the dorsal surface between the shoulders and the hips; length of tail less than
90 per cent of length of head and body; skull with conspicuous ridges;
extension of supraorbital ridges always evident on parietals; infraorbital
foramen usually with separate groove for transmission of nerve; palate usually
extended posteriorly as far as third molars; incisors opisthodont; molariform
teeth with a small main fold, never extended transversely to opposite wall in
occlusal surface of tooth; usually one counterfold anterior to main fold in
upper molariform teeth and posterior to main fold in lower molariform teeth;
premolars usually smaller than first molars, first molars smaller than second
molars but second molars larger than third molars.

Proechimys goeldii Thomas

General characters.—Size large; tail short; aristiforms narrow and soft, usually
concealed in pelage by setiforms; general color of upper parts some tint of
orange, gradually becoming lighter on sides with no conspicuous, dark
longitudinal band on back; feet dark; ventral surface of body and inner side of
legs white but sometimes with some buff locally; skull broad and strongly built
but not conspicuously ridged; zygomatic expanse great and rostrum not
elongate; incisive foramen narrow; bullae large and inflated; upper molariform
teeth with three to four counterfolds, M3 ordinarily with four; lower premolars
with four, and molars with three, counterfolds.

Proechimys goeldii steerei Goldman

Proechimys steerei Goldman, Proc. Biol. Soc. Washington, 24:238, 28

November 1911 (original description); Goldman, 1912, Proc. Biol. Soc.
Washington, 25:186; Tate, 1935, Bull. Amer. Mus. Nat. Hist., 68(5):400;
Ellerman, 1940, The families and genera of living rodents, Brit. Mus. (Nat.
Hist.), 1:119; Osgood, 1944, Zool. Ser. Field Mus. Nat. Hist., 29(13):204.
Type locality.—Hyutanaham, Upper Purus, Lábrea, Amazonas, Brazil. Type:
United States National Museum, no. 105535, adult male; collected in 1901 by
Prof. J. B. Steere.
Range.—Known only from the type locality and Porto Velho.
Diagnosis.—Upper parts Mars Orange on back, grading to Ochraceous-Tawny
on sides; zygomatic breadth narrow; nasals short; incisive foramen narrow
and short; vomerine sheath complete and thick; upper molars usually with
four counterfolds.
Pelage.—Aristiforms on middorsal region: Grayish basally, gradually blackening
toward tip; total length, 16 to 19 mm; maximum width, 0.5 mm. Setiforms on
middorsal region: Grayish on basal third, gradually blackening toward tip but
interrupted by a Mars Orange, subapical zone 1.5 mm long; total length, 16 to
19 mm; maximum width, 0.06 mm. Setiforms on outer thighs: Whitish basally,
gradually blackening toward tip but interrupted by Orange Rufous or
Ochraceous-Tawny, subapical zone; total length, 14 to 16 mm; maximum
width, 0.05 mm.
Figs. 25, 27. Proechimys goeldii steerei, sex ?,
"Hyutanaham," USNM no. 105537. × 1.
Figs. 26, 28. Proechimys goeldii goeldii, female,
AMNH no. 37488. × 1.
Figs. 29, 30. Proechimys goeldii steerei, sex ?,
USNM no. 105537, "Hyutanaham." × 1.
 Figs. 31, 32. Proechimys goeldii goeldii, female,
AMNH no. 37488, Fazenda Paraiso. × 1.

Skull.—Large and strong; rostrum rather pointed posteriorly; supraorbital

ridges not much expanded and extending across anterior half of parietals;
infraorbital foramen without groove for transmission of nerve, or groove
obsolete; zygomatic arches slender; postorbital process of zygoma involving
mostly squamosal; incisive foramen short and narrow (4.5 × 2.5 mm) with
margins almost parallel or tapering gradually caudad and extending toward
palate as ridges; posterior margin of incisive foramen approximately 2.5 mm
anterior to premolars; vomerine sheath complete, with both elements well-
developed; mesopterygoid fossa never extending anterior to middle of M3;
bullae large, well inflated and with shallow grooves.
Teeth.—Upper molariform teeth: P4 with three counterfolds; upper molars
with four counterfolds each or, less commonly, three. Lower premolars with
four counterfolds; lower molars with three each.
Comparisons.—From P. g. goeldii, steerei differs in: Back and sides with more
reddish; narrower interorbitally and across zygomata; palatilar length less and
nasals shorter; maxillary part of vomerine sheath thicker; usually four instead
of three counterfolds in M3.
Remarks.—This subspecies is clearly related to P. goeldii. One skull
from Porto Velho, Rio Madeira, Guaporé, Brazil (CNHM no. 21558)
may belong to an unnamed subspecies but is provisionally included
here.
In the field notes of Professor Joseph Beal Steere, an entry for no.
72 reads: "Big white bellied wood rats x two young found in nest of
grass on the ground with the two young—much darker young
female." No. 77 in his field notes corresponds to the type specimen.
Specimens examined.—Total number, 4, from Brazil, as follows: Amazonas.
Lábrea, Hyutanaham, 3 (USNM); Territ. Guaporé, Porto Velho, 1 (CNHM).

Proechimys goeldii goeldii Thomas

Proechimys goeldii Thomas, June 1905, Ann. Mag. Nat. Hist., 15 (ser.
7):587, (orig. descr.); Thomas, 1912, Ann. Mag. Nat. Hist., 9 (ser. 8):89;
 Thomas, 1920, Ann. Mag. Nat. Hist., 6 (ser. 9):277, Tate, 1935, Bull. Amer.
Mus. Nat. Hist., 68(5):400; Osgood, 1944, Zool. Ser. Field Mus. Nat. Hist.,
29(13):199.
Proechimys cayennensis goeldii, Ellerman, 1940, The families and genera of
living rodents, Brit. Mus. (Nat. Hist.), 1:121.
Type locality.—Santarem, Santarem, Pará, Brazil. Type: British Museum (Nat.
Hist.), no. 5.1.25.6, adult female; presented by Dr. E. A. Goeldi.
Range.—Margins of the Amazon, between Jamundá and Tapajoz rivers.
Diagnosis.—Upper parts Ochraceous-Tawny; wide across zygomata; nasals of
moderate length; incisive foramen long and narrow; vomerine sheath
complete but maxillary part slender; first and second upper molars with four
counterfolds.
Pelage.—Aristiforms on middorsal region: Whitish basally and gradually
blackening toward tip which is extended as long, thin filament; total length, 22
to 24 mm; maximum width, 0.5 mm. Setiforms on middorsal region: Gray
basally, gradually blackening toward tip but interrupted by Ochraceous-Tawny,
subapical zone 3.3 mm long; total length, 19 to 21 mm; maximum width, 0.06
mm. Setiforms on outer thighs: Whitish basally, gradually blackening toward
tip but interrupted by Ochraceous-Tawny, subapical zone 3 mm long; total
length 14 to 16 mm; maximum width, 0.04 mm.
Skull.—Large and strong; nasals pointed posteriorly; supraorbital ridges
moderately developed and extended caudad across anterior third of parietals;
zygomatic arches strong; postorbital process of zygoma involving mostly
squamosal; incisive foramen elongate and narrow (5 to 6.5 × 2.3 mm) with
margins more or less parallel and raised to form ridges which extend
posteriorly to within 3 mm of plane of premolars; vomerine sheath complete,
with maxillary part thin and extended caudad as medial crest; mesopterygoid
fossa extending forward as far as posterior faces of second molars or slightly
short thereof; bullae large and inflated.
Teeth.—Molariform teeth large, P4-M3 averaging more than 9 mm in length.
Upper molariform teeth: P4 and M3 with three counterfolds; M1 and M2 with
four counterfolds each. In lower teeth, p4 with four counterfolds and each
molar with three counterfolds.
Comparisons.—Differences from P. g. steerei are given in the account of that
subspecies.
Remarks.—Specimens from the type locality were not available.
Specimens from Fazenda Paraiso, Faro, were relied upon as
representative of the subspecies. These agree with the type
according to Thomas (1912:89). However, the skin of the type was
changed in color by preservative (Thomas, 1905:587) and the best
skin he saw was from Faro (1912:89).
Thomas (1920:277) applied the name goeldii also to specimens from
Manacaparú, a place a short distance above Manaus on the Solimões
(Amazon) River and from Acajutuba, near Manaus, on the Negro
River. In referring to these specimens (2 from Manacaparú and 2
from Acajutuba) Thomas (loc. cit.) said "Five molar laminae are
frequently, if not invariably, present among these specimens." He did
not, however, mention whether or not the number of laminae was
constant in both M2 and M3. One specimen from Acajutuba, in the
collection of Museu Nacional (MN no. 1973 [M]), actually has five
laminae in M3, but the specimens in the American Museum from
Faro agree absolutely with Thomas' original description of goeldii.
Osgood (1944:199) doubted that goeldii was a valid species.
Evidence that Osgood's doubt was unjustified is furnished by the fact
that Thomas (1912:89) pointed out that his specimen from Faro
agrees with the type. Likewise, my two specimens from Faro agree
with the type insofar as it has been described. Thomas (1912:89)
mentioned two additional skulls from the type locality which, he
stated, agree with the type which was received from the Museu
Goeldi, Pará.
Specimens examined.—Total number, 4, from Brazil as follows: Pará, Faro,
Faro, Fazenda Paraiso, 2 (AMNH); Amazonas, Manaus, Manaus, 1 skull
(AMNH); Amazonas, Manaus, Acajutuba, 1 (MN).
Additional records.—Total number, 7 (British Museum), from Brazil, as follows:
Pará, Santarem, Santarem (Thomas, 1912:89; 1920:277), 3; Amazonas,
Manaus, Acajutuba (Thomas, 1920:277), 2; Manacaparú, Manacaparú
(Thomas, 1920:277), 2.
Proechimys semispinosus (Tomes)

Figs. 33, 36. Proechimys semispinosus liminalis,

female, MN no. 6253, Rio Quichito. Type. × 1.
 Figs. 34, 37. Proechimys semispinosus
amphichoricus, male, AMNH no. 77020, Mount
Duida. Type. × 1.
Figs. 35, 38. Proechimys semispinosus kermiti,
female, AMNH no. 37124, Lower Rio Solimões.
Type. × 1.2 (from photograph).

General characters.—Size large; tail short and hairy; aristiforms wide and stiff,
especially well-developed on back; general color on upper parts some shade of
ochraceous, usually much darker on back and forming a conspicuous dorsal
band; feet dark; ventral surfaces and inner sides of legs white; skull elongate
and strong with ridges well developed; incisive foramen long and narrow;
bullae large; usually four counterfolds in M3 and M2; usually three but
sometimes four counterfolds in M1 and even P4; lower premolar with four and
lower molars with three counterfolds.
 Figs. 39, 40. Proechimys semispinosus liminalis,
female, MN no. 6253, Rio Quichito. Type. × 1.
Figs. 41, 42. Proechimys semispinosus
amphichoricus, male, AMNH no. 77020, Mount
Duida. Type. × 1.
Figs. 43, 44. Proechimys semispinosus kermiti,
female, AMNH no. 37124, Lower Rio Solimões.
Type. × 1.2 (from photograph).

Proechimys semispinosus liminalis subspecies nova

Type locality.—Rio Quichito, affluent from the south of the Javarí River, near
Benjamin Constant, Benjamin Constant, Amazonas, Brazil. Type: Museu
Nacional, no. 6253, adult female, collected in August, 1942, by E. Parko.
Range.—Known only from the type locality.
Diagnosis.—Color uniformly dark, setiforms marked with Ochraceous-Tawny;
skull wide across zygomata; nasals short; prepalatilar part of skull long;
incisive foramen long and narrow; vomerine sheath incomplete or complete;
M2 and M3 almost always with four counterfolds; M1 more rarely with four
counterfolds.
Pelage.—Aristiforms on middorsal region: Gray basally, gradually blackening
toward tip which is generally extended as a filament; total length, 21 to 23
mm; maximum width, 0.9 to 1 mm. Setiforms on middorsal region: Gray
basally, gradually blackening toward tip but interrupted by Ochraceous-
subapical Tawny, zone 3 mm long; total length, 22 to 24 mm; maximum width,
0.06 mm. Setiforms on outer thighs: Whitish basally, gradually blackening
toward tip but interrupted by Ochraceous-Buff, subapical zone 2.5 mm long;
total length, 13 to 15 mm; maximum width, 0.08 mm; some with gray base,
blackening gradually toward tip, without any subapical zone; some with Light
Ochraceous-Tawny, subapical zone.
Skull.—Large and strongly built throughout; supraorbital ridges expanded and
thick, extending, in old specimens, across parietals to anterior angles of
interparietals; interparietal ridges always conspicuous; rostrum elongated;
nasals blunt posteriorly; zygomatic arches strong; infraorbital foramen with
weakly-developed groove for transmission of nerve; postorbital process of
zygoma involving mostly squamosal; incisive foramen averaging 6 x 2.7 mm,
widest in middle part and posteriorly constricted, with raised margins which do
not extend across maxillae as ridges; posterior margin of incisive foramen
approximately 1.5 mm anterior to plane of premolars; vomerine sheath
incomplete or, sometimes, complete but always with maxillary part slender;
mesopterygoid fossa not extending forward past centers of third molars;
bullae moderately developed.
Teeth.—Upper molariform teeth: P4 always with three counterfolds; M1 with
three counterfolds in 9 of 10 specimens and four counterfolds in remainder;
M2 with four counterfolds in 7 specimens, three counterfolds in remainder; M3
with four counterfolds in 6 specimens, three counterfolds in remainder. Lower
premolar always with four, and molars with three, counterfolds.
Comparisons.—From P. s. semispinosus, liminalis differs in: darker color; wider
aristiforms; greater percentage of upper molars with four counterfolds. From
P. s. amphichoricus, liminalis differs in: lighter upper parts of almost uniform
color instead of with conspicuous, blackish, middorsal, longitudinal band; more
strongly built skull; longer incisive foramen; vomerine sheath usually
incomplete instead of always complete.
Specimens examined.—Total number, 10 (MN) from the type locality.

Proechimys semispinosus amphichoricus subspecies nova

Type locality.—Mount Duida, Esmeralda, Amazonas, Venezuela; altitude 325 m.

Type: American Museum of Natural History, no. 77020, adult male; collected
16 October 1920 by Olalla Bros.
Range.—Headwaters of Negro and Orinoco rivers, along boundary of Brazil
and Venezuela.
Diagnosis.—Color dark, blackish on middorsal area; subapical zone of
setiforms on back Buckthorn Brown, but many with distal parts black; skull
broad across zygomata; nasals long; prepalatilar area of skull long; incisive
foramen long and narrow; vomerine sheath complete; upper molars usually
with four counterfolds but P4 usually with only three.
Pelage.—Aristiforms on middorsal region: Grayish basally, gradually blackening
toward tip; total length, 18 to 20 mm; maximum width, 0.8 to 1.0 mm.
Setiforms on middorsal region: Gray basally, gradually blackening toward tip
but interrupted by a light (16 i), Buckthorn Brown, subapical zone 2 mm long;
total length, 18 to 22 mm; maximum width, 0.03 mm. Most of them, however,
whitish basally, gradually blackening toward tip without any distinctively-
colored, subapical zone; total length, 24 to 26 mm; maximum width, 0.5 mm.
Setiforms on outer thighs: Whitish basally, gradually blackening toward tip but
interrupted by an Ochraceous-Buff, subapical zone 3.5 mm long; black tip
short; total length, 17 to 19 mm; maximum width, 0.05 mm.
Skull.—Large and slender; rostrum elongate; nasals bluntly pointed
posteriorly; supraorbital ridges thick (but not expanded) and extending across
parietals but almost obsolete in middle part of parietals; infraorbital foramen
with weakly-developed groove for transmission of nerve; postorbital process of
zygoma involving mostly squamosal; incisive foramen 5.5 x 2.8 mm wide in
anterior third, with margins constricted posteriorly and extending as ridges
approximately 2 mm beyond posterior margin of incisive foramen; posterior
margin of incisive foramen approximately 2.5 mm anterior to premolars;
vomerine sheath complete with maxillary part weak and premaxillary part
extending posteriorly beyond middle of incisive foramen; mesopterygoid fossa
extending forward as far as middle of M3; bullae well inflated and elongated.
Teeth.—P4 with four counterfolds in one of five specimens and with three in
remainder; M1 with four counterfolds in three of five specimens and with three
in remainder; M2 with three counterfolds in one specimen and with four in all
four remaining specimens; M3 always with four counterfolds. Lower premolars
with four counterfolds and lower molars with only three.
Comparisons.—The subspecies is easily distinguishable from P. s. angularis by:
larger number of black setiforms on back, forming an almost black longitudinal
band; more elongate skull; larger and longer bulla; longer incisive foramen
which is more constricted posteriorly.
Specimens examined.—Total number, 6 (AMNH), as follows: Venezuela, territ.
Amazonas, Esmeralda, Mt. Duida, altitude 325 m., 4; Venezuela, territ.
Amazonas, Rio Cassiquiare, Quemapuré, 1; Brazil, Amazonas, São Gabriel, Rio
Uaupés or Caiari, Tatú, 1.

Proechimys semispinosus kermiti Allen

Proechimys kermiti Allen, 30 December 1915, Bull. Amer. Mus. Nat. Hist.,
34(22):629 (orig. descr.); Allen, 1916, Bull. Amer. Mus. Nat. Hist.,
35(30):569; Tate, 1935, Bull. Amer. Mus. Nat. Hist., 68(5):400; Ellerman,
1940, The families and genera of living rodents, Brit. Mus. (Nat. Hist.),
1:119.
Type locality.—Lower Rio Solimões (up the Solimões 50 to 60 miles on the
north bank of the river), Manacaparú, Amazonas, Brazil. Type: American
Museum of Natural History, no. 37124, adult female; collected 20 April, 1914,
by Leo E. Miller (Roosevelt Brazilian Expedition).
Range.—Known only from type locality.
Diagnosis.—Upper parts Tawny, with darker longitudinal band on back,
gradually becoming Ochraceous-Buff on sides; zygomata widely spread; nasals
long; incisive foramen long; vomerine sheath incomplete; only M3 with four
counterfolds.
Pelage.—Aristiforms on middorsal region: Grayish basally, gradually blackening
toward tip; total length, 18 to 20 mm; maximum width, 0.8 mm. Setiforms on
middorsal region: Grayish basally, gradually blackening toward tip but
interrupted by Tawny, subapical zone 2 mm long; total length, 18 to 20 mm;
maximum width, 0.06 mm; some blackened toward tip without subapical zone.
Setiforms on outer thighs: Whitish basally, gradually blackening toward tip but
interrupted by Ochraceous-Buff, subapical zone 2.5 mm long; total length, 18
to 20 mm; maximum width, 0.05 mm.
Skull.—Large, elongate, and strongly built; rostrum not conspicuously
elongated; nasals bluntly pointed posteriorly; supraorbital ridges wide and
extending posteriorly across parietals almost to level of interparietal;
infraorbital foramen with moderate development of groove for transmission of
nerve; zygomatic arches slender; postorbital process of zygoma involving
mostly squamosal; incisive foramen 6.5 mm long and 2.7 mm wide, wider in
anterior third and gradually constricted posteriorly, with margins extended
toward palate as ridges; vomerine sheath incomplete, maxillary part
threadlike; mesopterygoid fossa extending forward as far as anterior third of
m3; bullae large and well inflated.
Teeth.—P4 with three counterfolds; M3 with four counterfolds; M1 and M2
with three counterfolds. Lower premolars with four counterfolds; lower molars
with three counterfolds.
Comparisons.—From P. s. amphichoricus, kermiti differs in: upper parts Tawny
instead of Buckthorn Brown; incisive foramen longer and wider; vomerine
sheath incomplete; only M3 instead of usually all molars, with four
counterfolds. From P. s. liminalis, kermiti differs in: upper parts Tawny instead
of Ochraceous-Tawny; aristiforms narrower; M3 only, instead of usually M2
and M3, with four counterfolds.
Specimens examined.—Only the type.

Proechimys longicaudatus (Rengger)

General characters.—Size medium to large; tail short; aristiforms long and
narrow; general color on upper parts Ochraceous-Buff to Ochraceous-Orange,
finely and uniformly lined with blackish and not forming evident dark band on
back; feet dorsally white or gray; underparts of body and inner sides of legs
white; skull elongate and slender with moderate ridges; incisive foramen of
medium size; vomerine sheath complete or incomplete; bullae large and
 elongate; upper molariform teeth with three counterfolds; lower molariform
teeth with three counterfolds but commonly one or two molars have only two
although premolar may have four.
Remarks.—The identity of "Echimys longicaudatus Rengger" can be
ascertained only after samples have been collected in the area
indicated by Rengger: "unter dem ein und zwansigsten
Breitengrade" in Paraguay. Of the samples available to me, those
from Urucum, in western Brazil, are geographically nearest the type
locality. North of Urucum, both in Brazil and Bolivia, two species of
Proechimys live together and one of them is the same species as
that at Urucum. Of the two species found to the northward in Brazil
and Bolivia, the one that ranges farther south probably will occur at
the locality indicated by Rengger. Provisionally, therefore, the name
longicaudatus is allocated to the Urucum sample (see Osgood,
1944:198). In fact, the lack of a type specimen and the general
nature of Rengger's description make "Echimys longicaudatus" a
nomen vanum. If two species are found living together in the region
of northern Paraguay indicated by Rengger it probably will be
impossible to be sure to which one his vague description applies.
The form from Urucum, to which the name Proechimys
longicaudatus is here applied, is undoubtedly closely related to
Proechimys leucomystax Ribeiro, from Utiarití, on the Rio Papagaio
and also to P. roberti and P. boimensis, all from Brazil. P.
longicaudatus is used as the name of the species because it is the
oldest of the four names.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about testbank and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebooksecure.com