Chapter 1 The Database Approach

Chapter 1

The Database Approcah

Answers to Review Questions

1. Discuss each of the following terms:

a. data

Raw facts from which the required information is derived. Data have little meaning unless they
are grouped in a logical manner.

b. field

A character or a group of characters (numeric or alphanumeric) that describes a specific

characteristic. A field may define a telephone number, a date, or other specific characteristics
that the end user wants to keep track of.

c. record

A logically connected set of one or more fields that describes a person, place, event, or thing.
For example, a CUSTOMER record may be composed of the fields CUST_NUMBER,
CUST_LNAME, CUST_FNAME, CUST_INITIAL, CUST_ADDRESS, CUST_CITY,
CUST_COUNTRY, CUST_POSTCODE, CUST_AREACODE, and CUST_PHONE.

d. file

Historically, a collection of file folders, properly tagged and kept in a filing cabinet. Although
such manual files still exist, we more commonly think of a (computer) file as a collection of
related records that contain information of interest to the end user. For example, a sales
organization is likely to keep a file containing customer data. Keep in mind that the phrase
related records reflects a relationship based on function. For example, customer data are kept
in a file named CUSTOMER. The records in this customer file are related by the fact that they
all pertain to customers. Similarly, a file named PRODUCT would contain records that
describe products – the records in this file are all related by the fact that they all pertain to
products. You would not expect to find customer data in a product file, or vice versa.

NOTE
Note: Field, record, and file are computer terms, created to help describe how data are
stored in secondary memory. Emphasize that computer file data storage does not match
the human perception of such data storage.

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

2. What is data redundancy, and which characteristics of the file system can lead to it?

Data redundancy exists when unnecessarily duplicated data are found in the database. For example,
a customer's telephone number may be found in the customer file, in the sales agent file, and in the
invoice file. Data redundancy is symptomatic of a (computer) file system, given its inability to
represent and manage data relationships. Data redundancy may also be the result of
poorly-designed databases that allow the same data to be kept in different locations. (Here's another
opportunity to emphasize the need for good database design!)

3. Discuss the lack of data independence in file systems.

File systems exhibit data dependence because file access is dependent on a file's data
characteristics. Therefore, any time the file data characteristics are changed, the programs that
access the data within those files must be modified. Data independence exists when changes in the
data characteristics don't require changes in the programs that access those data.

4. What is a DBMS, and what are its functions?

A DBMS is best described as a collection of programs that manage the database structure and that
control shared access to the data in the database. Current DBMSes also store the relationships
between the database components; they also take care of defining the required access paths to those
components. The functions of a current-generation DBMS may be summarized as follows:
 The DBMS stores the definitions of data and their relationships (metadata) in a data dictionary;
any changes made are automatically recorded in the data dictionary.
 The DBMS creates the complex structures required for data storage.
 The DBMS transforms entered data to conform to the data structures in item 2.
 The DBMS creates a security system and enforces security within that system.
 The DBMS creates complex structures that allow multiple-user access to the data.
 The DBMS performs backup and data recovery procedures to ensure data safety.
 The DBMS promotes and enforces integrity rules to eliminate data integrity problems.
 The DBMS provides access to the data via utility programs and from programming
languages interfaces.
 The DBMS provides end-user access to data within a computer network environment.

5. What is data independence, and why is it important?

Data independence exists when data access programs are not subject to change when any of the
file's data characteristics change. Data independence is important because it substantially decreases
programming effort and program maintenance costs.

6. Explain the difference between data and information.

Data are raw facts. Information is processed data to reveal the meaning behind the facts. The
following summary
Let’s summarize some key points:
 Data constitute the building bocks of information.

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

 Information is produced by processing data.

 Information is used to reveal the meaning of data.
 Good, relevant, and timely information is the key to good decision making.
 Good decision making is the key to organizational survival in a global environment.

7. What is the role of a DBMS, and what are its advantages?

A database management system (DBMS) is a collection of programs that manages the database
structure and controls access to the data stored in the database. Figure 1.2 (shown in the text)
illustrates that the DBMS serves as the intermediary between the user and the database. The DBMS
receives all application requests and translates them into the complex operations required to fulfill
those requests. The DBMS hides much of the database’s internal complexity from the application
programs and users. The application program might be written by a programmer using a
programming language such as COBOL, Visual Basic, C++ OR Java or it might be created through
a DBMS utility program.

Having a DBMS between the end user’s applications and the database offers some important
advantages. First, the DBMS enables the data in the database to be shared among multiple
applications or users. Second, the DBMS integrates the many different users’ views of the data into
a single all-encompassing data repository.

Because data are the crucial raw material from which information is derived, you must have a good
way of managing such data. As you will discover in this book, the DBMS helps make data
management more efficient and effective. In particular, a DBMS provides advantages such as:
 Improved data sharing. The DBMS helps create an environment in which end users have
better access to more and better-managed data. Such access makes it possible for end users to
respond quickly to changes in their environment.
 Better data integration. Wider access to well-managed data promotes an integrated view of
the organization’s operations and a clearer view of the big picture. It becomes much easier to
see how actions in one segment of the company affect other segments.
 Minimized data inconsistency. Data inconsistency exists when different versions of the same
data appear in different places. For example, data inconsistency exists when a company’s
sales department stores a sales representative’s name as “Bill Brown” and the company’s
personnel department stores that same person’s name as “William G. Brown” or when the
company’s regional sales office shows the price of product “X” as €45.95 and its national
sales office shows the same product’s price as €43.95. The probability of data inconsistency
is greatly reduced in a properly designed database.
 Improved data access. The DBMS makes it possible to produce quick answers to ad hoc
queries. From a database perspective, a query is a specific request for data manipulation (for
example, to read or update the data) issued to the DBMS. Simply put, a query is a question
and an ad hoc query is a spur-of-the-moment question. The DBMS sends back an answer
(called the query result set) to the application. For example, end users, when dealing with
large amounts of sales data, might want quick answers to questions (ad hoc queries) such as:
 What was the euro volume of sales by product during the past six months?
 What is the sales bonus figure for each of our salespeople during the past three
months?

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

 How many of our customers have credit balances of €3,000 or more?

 Improved decision making. Better-managed data and improved data access make it possible
to generate better quality information, on which better decisions are based.
 Increased end-user productivity. The availability of data, combined with the tools that
transform data into usable information, empowers end users to make quick, informed
decisions that can make the difference between success and failure in the global economy.

The advantages of using a DBMS are not limited to the few just listed. In fact, you will discover
many more advantages as you learn more about the technical details of databases and their proper
design.

8. List and describe the different types of databases.

The focus is on Section 1.2.2, TYPES OF DATABASES. Organize the discussion around the
number of users, database site location, and data use:
 Number of users
 Single-user
 Multiuser
 Workgroup
 Enterprise
 Database site location
 Centralized
 Distributed
 Database use
 Transactional (production) database
 Data warehouse database

9. What are the main components of a database system?

The basis of this discussion is Section 1.6.1, THE DATABASE SYSTEM ENVIRONMENT.
Figure 1.7 provides a good bird’s eye view of the components. Note that the system’s components
are hardware, software, people, procedures, and data.

10. What is metadata?

Metadata is data about data. That is, metadata define the data characteristics such as the data type
(such as character or numeric) and the relationships that link the data. Relationships are an
important component of database design. What makes relationships especially interesting is that
they are often defined by their environment. For instance, the relationship between EMPLOYEE
and JOB is likely to depend on the organization’s definition of the work environment. For example,
in some organizations an employee can have multiple job assignments, while in other organizations
– or even in other divisions within the same organization – an employee can have only one job
assignment.

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

The details of relationship types and the roles played by those relationships in data models are
defined and described in Chapter 2, Data Models.”. Relationships will play a key role in subsequent
chapters. You cannot effectively deal with database design issues unless you address relationships.

11. Explain why database design is important.

The focus is on Section 1.3, WHY DATABASE DESIGN IS IMPORTANT. Explain that modern
database and applications development software is so easy to use that many people can quickly learn
to implement a simple database and develop simple applications within a week or so, without giving
design much thought. As data and reporting requirements become more complex, those same people
will simply (and quickly!) produce the required add-ons. That's how data redundancies and all their
attendant anomalies develop, thus reducing the "database" and its applications to a status worse than
useless. Stress these points:
 Good applications can't overcome bad database designs.
 The existence of a DBMS does not guarantee good data management, nor does it ensure that
the database will be able to generate correct and timely information.
 Ultimately, the end user and the designer decide what data will be stored in the database.

A database created without the benefit of a detailed blueprint is unlikely to be satisfactory. Pose this
question: would you think it smart to build a house without the benefit of a blueprint? So why
would you want to create a database without a blueprint? (Perhaps it would be OK to build a
chicken coop without a blueprint, but would you want your house to be built the same way?)

12. What are the potential costs of implementing a database system?

Although the database system yields considerable advantages over previous data management
approaches, database systems do impose significant costs. For example:
 Increased acquisition and operating costs. Database systems require sophisticated hardware
and software and highly skilled personnel. The cost of maintaining the hardware, software,
and personnel required to operate and manage a database system can be substantial.
 Management complexity. Database systems interface with many different technologies and
have a significant impact on a company's resources and culture. The changes introduced by
the adoption of a database system must be properly managed to ensure that they help advance
the company's objectives. Given the fact that databases systems hold crucial company data
that are accessed from multiple sources, security issues must be assessed constantly.
 Maintaining currency. To maximize the efficiency of the database system, you must keep
your system current. Therefore, you must perform frequent updates and apply the latest
patches and security measures to all components. Because database technology advances
rapidly, personnel training costs tend to be significant.
 Vendor dependence. Given the heavy investment in technology and personnel training,
companies may be reluctant to change database vendors. As a consequence, vendors are less
likely to offer pricing point advantages to existing customers and those customers may be
limited in their choice of database system components.

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

Problem Solutions

ONLINE CONTENT
The file structures you see in this problem set are simulated in a Microsoft Access database named
Ch01_Problems, available in the Premium Website for this book. The Premium Website also
includes SQL script files (Oracle and SQLServer) for all of the data sets used throughout the
book.

Given the file structure shown in Figure P1.1, answer Problems 1 - 4.

FIGURE P1.1 The File Structure for Problems 1-4

PROJECT_CODE PROJECT_MANAGER MANAGER_PHONE MANAGER_ADDRESS PROJECT_BID_PRICE
21-5Z Holly B. Parker 33-5-59200506 180 Boulevard du Général, Paris,64700 €13,179,975.00
25-2D Jane D. Grant 0181-898-9909 218 Clark Blvd., London, NW3 TRY €9,787,037.00
25-5A George F. Dorts 0181-227-1245 124 River Dr., London, N6 7YU €25,458,005.00
25-9T Holly B. Parker 33-5-59200506 180 Boulevard du Général, Paris,64700 €16,887,181.00
27-4Q George F. Dorts 0181-227-1245 124 River Dr., London, NW2 5TY €8,078,124.00
29-2D Holly B. Parker 33-5-59200506 180 Boulevard du Général, Paris,64700 €20,014,885.00
31-7P William K. Moor 39-064885889 Via Valgia Silvilla 23, Roma, 00179 €44,516,677.00

1. How many records does the file contain, and how many fields are there per record?

The file contains seven records (21-5Z through 31-7P) and each of the records is composed of five
fields (PROJECT_CODE through PROJECT_BID_PRICE.)

2. What problem would you encounter if you wanted to produce a listing by city? How would you
solve this problem by altering the file structure?

The city names are contained within the MANAGER_ADDRESS attribute and decomposing this
character (string) field at the application level is cumbersome at best. (Queries become much more
difficult to write and take longer to execute when internal string searches must be conducted.) If the
ability to produce city listings is important, it is best to store the city name as a separate attribute.

3. If you wanted to produce a listing of the file contents by last name, area code, city, county, or
postcode, how would you alter the file structure?

The more we divide the address into its component parts, the greater its information capabilities.
For example, by dividing MANAGER_ADDRESS into its component parts (MGR_STREET,
MGR_CITY, and MGR_POSTCODE), we gain the ability to easily select records on the basis of
postcodes, city names, and even countries. Similarly, by subdividing the MANAGER name into its
components MGR_LASTNAME, MGR_FIRSTNAME, and MGR_INITIAL, we gain the ability to
produce more efficient searches and listings. For example, creating a phone directory is easy when
you can sort by last name, first name, and initial. Finally, separating the area code and the phone
number will yield the ability to efficiently group data by area codes. Thus MGR_PHONE might be

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

decomposed into MGR_AREA_CODE and MGR_PHONE. The more you decompose the data into
their component parts, the greater the search flexibility. Data that are decomposed into their most
basic components are said to be atomic.

4. What data redundancies do you detect, and how could these redundancies lead to anomalies?

Note that the manager named Holly B. Parker occurs three times, indicating that she manages three
projects coded 21-5Z, 25-9T, and 29-2D, respectively. (The occurrences indicate that there is a 1:*
relationship between PROJECT and MANAGER: each project is managed by only one manager
but, apparently, a manager may manage more than one project.) Ms. Parker's phone number and
address also occur three times. If Ms. Parker moves and/or changes her phone number, these
changes must be made more than once and they must all be made correctly... without missing a
single occurrence. If any occurrence is missed during the change, the data are "different" for the
same person. After some time, it may become difficult to determine what the correct data are. In
addition, multiple occurrences invite misspellings and digit transpositions, thus producing the same
anomalies. The same problems exist for the multiple occurrences of George F. Dorts.

5. Identify and discuss the serious data redundancy problems exhibited by the file structure shown in
Figure P1.2.

FIGURE P1.2 The File Structure for Problems 5-8

PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CODE JOB_CHG_HOUR PROJ_HOURS EMP_PHONE
1 Hurricane 101 John D. Newson EE €65.00 13.3 31-20-6226060
1 Hurricane 105 David F. Schwann CT €40.00 16.2 0191-234-1123
1 Hurricane 110 Anne R. Ramoras CT €40.00 14.3 34-934412463
2 Coast 101 John D. Newson EE €65.00 19.8 31-20-6226060
2 Coast 108 June H. Sattlemeir EE €65.00 17.5 0161-554-7812
3 Satellite 110 Anne R. Ramoras CT €42.00 11.6 34-934412463
3 Satellite 105 David F. Schwann CT €6.00 23.4 0191-234-1123
3 Satelite 123 Mary D. Chen EE €65.00 19.1 0181-233-5432
3 Satellite 112 Allecia R. Smith BE €65.00 20.7 0181-678-6879

NOTE
It is not too early to begin discussing proper structure. For example, you may focus
student attention on the fact that, ideally, each row should represent a single entity.
Therefore, each row's fields should define the characteristics of one entity, rather than
include characteristics of several entities. The file structure shown here includes
characteristics of multiple entities. For example, the JOB_CODE is likely to be a
characteristic of a JOB entity. PROJ_NUM and PROJ_NAME are clearly characteristics
of a PROJECT entity. Also, since (apparently) each project has more than one employee
assigned to it, the file structure shown here shows multiple occurrences for each of the
projects. (Hurricane occurs three times, Coast occurs twice, and Satellite occurs four
times.)

Given the file's poor structure, the stage is set for multiple anomalies. For example, if the charge for
JOB_CODE = EE changes from €65.00 to €80.00, that change must be made twice. Also, if

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

employee June H. Sattlemeier is deleted from the file, you also lose information about the existence
of her JOB_CODE = EE, its hourly charge of €65.00, and the PROJ_HOURS = 17.5. The loss of
the PROJ_HOURS value will ultimately mean that the Coast project costs are not being charged
properly, thus causing a loss of PROJ_HOURS*JOB_CHG_HOUR = 17.5 x €65.00 = €1,137.50 to
the company.

Incidentally, note that the file contains different JOB_CHG_HOUR values for the same CT job
code, thus illustrating the effect of changes in the hourly charge rate over time. The file structure
appears to represent transactions that charge project hours to each project. However, the structure of
this file makes it difficult to avoid update anomalies and it is not possible to determine whether a
charge change is accurately reflected in each record. Ideally, a change in the hourly charge rate
would be made in only one place and this change would then be passed on to the transaction based
on the hourly charge. Such a structural change would ensure the historical accuracy of the
transactions.

You might want to emphasize that the recommended changes require a lot of work in a file system.

6. Looking at the EMP_NAME and EMP_PHONE contents in Figure P1.2, what change(s)
would you recommend?

A good recommendation would be to make the data more atomic. That is, break up the data
componnts whenever possible. For example, separate the EMP_NAME into its componenst
EMP_FNAME, EMP_INITIAL, and EMP_LNAME. This change will make it much easier to
organize employee data through the employee name component. Similarly, the EMP_PHONE data
should be decomposed into EMP_AREACODE and EMP_PHONE. For example, breaking up the
phone number 0191-234-1123 into the area code 0191 and the phone number 234-1123 will make it
much easier to organize the phone numbers by area code. (If you want to print an employee phone
directory, the more atomic employee name data will make the job much easier.)

7. Identify the different data sources in the file you examined in Problem 5.

Given their answers to problem 5 and some additional scrutiny of Figure 1.5, your students should
be able to identify these data sources:
 Employee data such as names and phone numbers.
 Project data such as project names. If you start with an EMPLOYEE file, the project names
clearly do not belong in that file. (Project names are clearly not employee characteristics.)
 Job data such as the job charge per hour. If you start with an EMPLOYEE file, the job charge
per hour clearly does not belong in that file. (Hourly charges are clearly not employee
characteristics.)
 The project hours, which are most likely the hours worked by the employee for that project.
(Such hours are associated with a work product, not the employee per se.)

8. Given your answer to Problem 7, what new files should you create to help eliminate the data
redundancies found in the file shown in Figure P1.2?

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA
 Chapter 1 The Database Approach

The data sources are probably the PROJECT, EMPLOYEE, JOB, and CHARGE. The PROJECT
file should contain project characteristics such as the project name, the project
manager/coordinator, the project budget, and so on. The EMPLOYEE file might contain the
employee names, phone number, address, and so on. The JOB file would contain the billing charge
per hour for each of the job types – a database designer, an applications developer, and an
accountant would generate different billing charges per hour. The CHARGE file would be used to
keep track of the number of hours by job type that will be billed for each employee who worked on
the project.

9. Identify and discuss the serious data redundancy problems exhibited by the file structure shown in
Figure P1.3. (The file is meant to be used as a teacher class assignment schedule. One of the many
problems with data redundancy is the likely occurrence of data inconsistencies – note that two
different initials have been entered for the teacher named Maria Cordoza.)

FIGURE P1.3 The File Structure for Problems 9-10

BUILDING_CODE ROOM_CODE TEACHER_LNAME TEACHER_FNAME TEACHER_INITIAL DAYS_TIME
KOM 204E Williston Horace G MWF 8:00-8:50
KOM 123 Cordoza Maria L MWF 8:00-8:50
LDB 504 Patroski Donald J TTh 1:00-2:15
KOM 34 Hawkins Anne W MWF 10:00-10:50
JKP 225B Risell James TTh 9:00-10:15
LDB 301 Robertson Jeanette P TTh 9:00-10:15
KOM 204E Cordoza Maria I MWF 9:00-9:50
LDB 504 Williston Horace G TTh 1:00-2:15
KOM 34 Cordoza Maria L MWF 11:00-11:50
LDB 504 Patroski Donald J MWF 2:00-2:50

Note that the teacher characteristics occur multiple times in this file. For example, the teacher named
Maria Cordoza’s first name, last name, and initial occur three times. If changes must be made for
any given teacher, those changes must be made multiple times. All it takes is one incorrect entry or
one forgotten change to create data inconsistencies. Redundant data are not a luxury you can afford
in a data environment.

10. Given the file structure shown in Figure P1.3 what problem(s) might you encounter if building
KOM were deleted?

You would lose all the time assignment data about teachers Williston, Cordoza, and Hawkins, as
well as the KOM rooms 204E, 123, and 34. Here is yet another good reason for keeping data about
specific entities in their own tables! This kind of an anomaly is known as a deletion anomaly.

For use with Database Principles 2nd Edition

© 2013 Cengage Learning EMEA