Systems Analysis and

Design 10th Edition

Chapter 9 – Data Design
Chapter Objectives
 Explain file-oriented systems and how they
differ from database management systems
 Explain data design terminology, including

entities, fields, common fields, records,

files, tables, and key fields
 Describe data relationships, draw an entity

relationship diagram, define cardinality, and

use cardinality notation

2
Chapter Objectives (Cont.)

 Explain the concept of normalization

 Explain the importance of codes and

describe various coding schemes

 Explain data warehousing and data mining
 Differentiate between logical and physical

storage and records

 Explain data control measures

3
 Data Design Concepts
 Data Structures
◦ A framework for organizing, storing, and
managing data
◦ Consists of files or tables that interact in various
ways
 Each file or table contains data about people, places,
things, or events

FIGURE 9-1 Typical data design task list

4
 Data Design Concepts (Cont.)

 Mario
and Danica: A Data Design
Example
◦ Mario’s Auto Shop
 Mario relies on two file oriented systems, that
store data in separate files that are not connected
 The MECHANIC SYSTEM uses the MECHANIC file to
store data about shop employees
FIGURE 9-2 In the example shown
 The JOB SYSTEM uses the JOB file to store data here, data about the mechanic, the
about work performed at the shop customer, and the brake job might
be stored in a file-oriented system
◦ Danica’s Auto Shop or in a database system
 Uses a database management system (DBMS) with
two separate tables that are joined, so they act like
one large table
 In Danica’s SHOP OPERATIONS SYSTEM, the tables
are linked by the Mechanic No field, which is called
a common field because it connects the tables

5
 Data Design Concepts (Cont.)

Mario’s Auto Shop Danica’s Auto Shop

FIGURE 9-4 Danica’s SHOP OPERATIONS

SYSTEM uses a database design, which
avoids duplication. The data can be viewed as
if it were one large table, regardless of where
the data is stored physically

FIGURE 9-3 Mario’s shop uses two separate

systems, so certain data must be entered twice. This
redundancy is inefficient, and can produce data
errors

6
 Data Design Concepts (Cont.)

• Is File Processing Still Important?

• Handles large volumes of structured data on a
regular basis
• Can be cost-effective
• Great for transaction processing
• The Database Environment
• A database management system (DBMS) is a
collection of tools, features, and interfaces that
enables users to add, update, manage, access, and
analyze data

7
Data Design Concepts (Cont.)

FIGURE 9-5 A credit card

company that posts thousands
of daily transactions might
consider a file processing
option

8
 Data Design Concepts (Cont.)

DBMS Advantages
• Scalability - A system can be expanded, modified, or
downsized
• Economy of scale - Database design allows better
utilization of hardware
• Enterprise-wide application - A database
administrator (DBA) assesses overall requirements
and maintains the database for the entire
• Stronger standards - Standards for data names,
formats, and documentation are followed uniformly
throughout the organization

9
 Data Design Concepts (Cont.)

DBMS Advantages
• Better security - The DBA ensures that only legitimate
users access the database and different users have
different levels of access
• Data independence - Systems that interact with a
DBMS are relatively independent of how the physical
data is maintained
• That design provides the DBA flexibility to alter
data structures without modifying information
systems that use the data

10
 DBMS Components
• Interfaces for Users, Database
Administrators, and Related Systems
• USERS
• Typically work with predefined queries and
switchboard commands, but also use query
languages to access stored data
• DATABASE ADMINISTRATORS
• Concerned with data security and integrity,
preventing unauthorized access, providing
backup and recovery, audit trails,
FIGURE 9-7 In addition to interfaces maintaining the database, and supporting
for users, database administrators, user needs
and related information systems, a • RELATED INFORMATION SYSTEMS
DBMS also has a data manipulation • A DBMS can support several related
language, a schema and information systems that provide input to,
subschemas, and a physical data
and require specific data from, the DBMS
repository

11
 DBMS Components (Cont.)

• Data Manipulation Language

• A data manipulation language (DML) controls
database operations, including storing, retrieving,
updating, and deleting data
• Schema
• The complete definition of a database, including
descriptions of all fields, tables, and relationships, is
called a schema
• Physical Data Repository
• The complete definition of a database, including
descriptions of all fields, tables, and relationships, is
called a schema

12
 Web-Based Data Design
• Overview
• A data manipulation language (DML) controls database
operations, including storing, retrieving, updating, and
deleting data
• Connecting to the Web
• The objective is to connect the database to the Web and
enable data to be viewed and updated
• Middleware - software that integrates different applications
and allows them to exchange data and interpret client
requests in HTML form; then translate the requests into
commands that the database can execute
• Data Security
• Web-based data must be secure, yet easily accessible to
authorized users

13
Web-Based Data Design (Cont.)

FIGURE 9-9 A Web-based design characteristics include global access,

ease of use, multiple platforms, cost effectiveness, security issues, and
adaptability issues. In a Web-based design, the Internet serves as the
front end, or interface, for the database management system. Access to
the database requires only a Web browser and an Internet connection

14
Web-Based Data Design (Cont.)

FIGURE 9-10 When a client workstation requests a Web page (1), the
Web server uses middleware to generate a data query to the database
server (2). The database server responds (3), and middleware
translates the retrieved data into an HTML page that can be sent by the
Web server and displayed by the user’s browser (4)

15
 Data Design Terms
• Definitions:
• ENTITY
• An entity is a person, place, thing, or event for which data
is collected and maintained
• TABLE OR FILE
• A table, or file, contains a set of related records that store
data about a specific entity
• FIELD
• A field, also called an attribute, is a single characteristic
or fact about an entity
• RECORD
• A record, also called a tuple (rhymes with couple), is a set
of related fields that describes one instance, or
occurrence, of an entity, such as one customer, one
order, or one product

16
 Data Design Terms (Cont.)

• Key Fields:
• PRIMARY KEY
• A field or combination of fields that uniquely and
minimally identifies a particular member of an entity
• CANDIDATE KEY
• Any field that could serve as a primary key is called a
candidate key
• FOREIGN KEY
• A common field that exists in more than one table and
can be used to form a relationship, or link, between the
tables
• SECONDARY KEY
• A field or combination of fields that can be used to access
or retrieve records

17
 Data Design Terms (Cont.)

• Referential Integrity:
• A set of rules that
avoids data
inconsistency and
quality problems. In
a relational database,
referential integrity
means that a foreign
key value cannot be
entered in one table
unless it matches an
existing primary key
in another table
FIGURE 9-13 Microsoft Access allows a user to specify that
referential integrity rules will be enforced in a relational
database design
18
 Entity-Relationship Diagrams
• Drawing an ERD
• The first step is to list the entities
that you identified during the
systems analysis phase and to
consider the nature of the
relationships that link them
• Types of Relationships
• Three types of relationships can
exist between entities:
• One-to-one
• One-to-many
• Many-to-many

FIGURE 9-14 In an entity-relationship diagram, entities are

labeled with singular nouns and relationships are labeled
with verbs. The relationship is interpreted as a simple
English sentence.
19
 Entity-Relationship Diagrams
(Cont.)

• A one-to-one relationship,
abbreviated 1:1, exists
when exactly one of the
second entity occurs for
each instance of the first
entity
• Figure 9-15 shows
examples of several 1:1
relationships
• A number 1 is placed
alongside each of the two
FIGURE 9-15 Examples of one-to-one (1:1) connecting lines to
relationships
indicate the 1:1
relationship

20
 Entity-Relationship Diagrams
(Cont.)

• A one-to-many
relationship, abbreviated
1:M, exists when one
occurrence of the first
entity can relate to many
instances of the second
entity, but each instance of
the second entity can
associate with only one
instance of the first entity

FIGURE 9-16 Examples of one-to-many

(1:M) relationships

21
Entity-Relationship Diagrams
(Cont.)

• A many-to-many
relationship,
abbreviated M:N,
exists when one
instance of the first
entity can relate to
many instances of
the second entity,
and one instance of
the second entity
can relate to many
instances of the first
entity
FIGURE 9-17 Examples of many-to-many (M:N) relationships.
Notice that the event or transaction that links the two entities is
an associative entity with its own set of attributes and
characteristics
22
Entity-Relationship Diagrams
(Cont.)

FIGURE 9-18 An entity-relationship diagram for SALES REP,

CUSTOMER, ORDER, PRODUCT, and WAREHOUSE. Notice
that the ORDER and PRODUCT entities are joined by an
associative entity named ORDER LINE

23
 Entity-Relationship Diagrams
(Cont.)

• Cardinality
• Describes the numeric
relationship between
two entities and shows
how instances of one
entity relate to instances
of another entity
• A common method of
cardinality notation is
called crow’s foot
notation because of the
shapes, which include
circles, bars, and symbols,
FIGURE 9-19 Crow’s foot notation is a
that indicate various possibilities common method of indicating cardinality.
The four examples show how you can use
various symbols to describe the
relationships between entities
24
Entity-Relationship Diagrams
(Cont.)
FIGURE 9-20 In the
first example of
cardinality notation,
one and only one
CUSTOMER can place
anywhere from zero to
many of the ORDER
entity.
In the second example,
one and only one
ORDER can include
one ITEM ORDERED
or many.
In the third example,
one and only one
EMPLOYEE can have
one SPOUSE or none.
In the fourth example,
one EMPLOYEE, or
many employees, or
none, can be assigned
to one PROJECT, or
many projects, or none

25
Entity-Relationship Diagrams
(Cont.)

FIGURE 9-21 An ERD for a library system

drawn with Visible Analyst. Notice
that crow’s foot notation has been used and
relationships are described in both
directions

26
 Data Normalization
• Normalization is the process of creating table
designs by assigning specific fields or attributes to
each table in the database
• Normalization involves applying a set of rules that
can help you identify and correct inherent
problems and complexities in your table designs
• The normalization process typically involves four
stages:
• Unnormalized design
• First normal form
• Second normal form
• Third normal form

27
 Data Normalization (Cont.)

• Standard Notation Format

• Starts with the name of the table, followed by a
parenthetical expression that contains the field
names separated by commas. The primary key
field(s) is underlined, like this:
• NAME (FIELD 1, FIELD 2, FIELD 3)
• A repeating group is a set of one or more fields
that can occur any number of times in a single
record, with each occurrence having different
values

28
Data Normalization (Cont.)

FIGURE 9-22 In the ORDER table design, two orders have repeating groups
that contain several products. ORDER is the primary key for the ORDER table,
and PRODUCT NUMBER serves as a primary key for the repeating group.
Because it contains repeating groups, the ORDER table is unnormalized

29
 Data Normalization (Cont.)

• First Normal Form (1NF)

• A table is in first normal form (1NF) if it does not
contain a repeating group
• When you eliminate the repeating group, additional
records emerge — one for each combination of a
specific order and a specific product
• The result is more records, but a greatly
simplified design

30
Data Normalization (Cont.)

FIGURE 9-23 The ORDER table as it

appears in 1NF. The repeating groups
have been eliminated. Notice that the
repeating group for order 86223 has
become three separate records, and
the repeating group for order 86390
has become two separate records. The
1NF primary key is a combination of
ORDER and PRODUCT NUMBER,
which uniquely identifies each record
31
 Data Normalization (Cont.)

• Second Normal Form (2NF)

• Must understand the concept of functional
Dependence
• Field A is functionally dependent on Field B if
the value of Field A depends on Field B
• A DATE value is functionally dependent on an
ORDER, because for a specific order number,
there can be only one date
• Objective is to break the original table into two
or more new tables and reassign the fields so
that each non-key field will depend on the
entire primary key in its table

32
Data Normalization (Cont.)

FIGURE 9-24 ORDER, PRODUCT,

and ORDER LINE tables in 2NF. All
fields are functionally dependent on
the primary key

33
 Data Normalization (Cont.)

• Third Normal Form (3NF)

• A design is in 3NF if every non-key field depends
on the key, the whole key, and nothing but the key
• A 3NF design avoids redundancy and data integrity
problems that still can exist in 2NF designs
• To convert the table to 3NF, you must remove all
fields from the 2NF table that depend on another
non-key field and place them in a new table that
uses the non-key field as a primary key

34
Data Normalization (Cont.)

FIGURE 9-25 When the PRODUCT

table is transformed from 2NF to 3F,
the result is two separate tables:
PRODUCT and SUPPLIER. Note that
in 3NF, all fields depend on the key,
the whole key, and nothing but the key!

35
 Two Real-World Examples
Example 1: Crossroads College

FIGURE 9-27 An initial

entity-relationship
diagram for ADVISOR,
STUDENT, and COURSE

FIGURE 9-28 The STUDENT table is unnormalized because it contains a

repeating group that represents the courses each student has taken
36
Two Real-World Examples (Cont.)

FIGURE 9-29 The STUDENT

table in 1NF. Notice that the
primary key has been expanded
to include STUDENT NUMBER
and COURSE NUMBER

37
Two Real-World Examples (Cont.)

FIGURE 9-30 The STUDENT,

COURSE, and GRADE tables in
2NF. Notice that all fields are
functionally dependent on the
entire primary key of their
respective tables
38
Two Real-World Examples (Cont.)

FIGURE 9-31 STUDENT, ADVISOR, COURSE, and

GRADE tables in 3NF. When the STUDENT table is
transformed from 2NF to 3NF, the result is two tables:
STUDENT and ADVISOR 39
Two Real-World Examples (Cont.)

FIGURE 9-32 The entity-relationship diagram for STUDENT,

ADVISOR, and COURSE after normalization. The GRADE entity was
identified during the normalization process. GRADE is an associative
entity that links the STUDENT and COURSE tables
40
 Two Real-World Examples (Cont.)

Example 2: Magic Maintenance

FIGURE 9-33 A
relational database
design for a computer
service company uses
common fields to link
the tables and form an
overall data structure.
Notice the one-to-
many notation
symbols, and the
primary keys, which
are indicated with
gold-colored key
symbols

41
Two Real-World Examples (Cont.)

FIGURE 9-34 Sample

data, primary keys,
and common fields for
the database shown in
Figure 9-33.
The design is in 3NF.
Notice that all nonkey
fields functionally
depend on a primary
key, the whole primary
key, and nothing but
the primary key

42
Working with a Relational Database
 Suppose you work in IT, and the sales team
needs answers to three specific questions
◦ Did any customers receive service after
12/14/2013? If so, who were they?
◦ Did technician Marie Johnson put in more than
six hours of labor on any service calls? If so,
which ones?
◦ Were any parts used on service calls in
Washington? If so, what were the part numbers,
descriptions, and quantities?

43
Working with a Relational Database
(Cont.)

FIGURE 9-35 Question 1 44

Working with a Relational Database
(Cont.)

FIGURE 9-36 Question 2 45

Working with a Relational Database
(Cont.)

FIGURE 9-37 Question 3 46

 Should You Use Codes?
 Overview of Codes
◦ Because codes can represent data and they are
shorter than the data they represent, they save
storage space and costs, reduce data
transmission time, and decrease data entry time
◦ Codes can be used to reveal or conceal
information
◦ Codes can reduce data input errors
◦ Coded data is easier to remember
◦ The code itself can provide immediate
verification that the entry is correct

47
 Should You Use Codes? (Cont.)

 Types of Codes
◦ Codes should be easy to learn and apply
◦ Sequence Codes
 Numbers or letters assigned in a specific order
 Contain no additional information other than an
indication of order of entry into the system
◦ Block sequence codes
 Use blocks of numbers for different classifications
 100-level courses are freshman-level
 200-level courses are sophomore-level

48
 Should You Use Codes? (Cont.)

 Types of Codes (Cont.)

◦ Alphabetic codes
 Use alphabet letters to distinguish one item from
another
 Category codes identify a group of related items
 A department store may use a two-character category code to
identify the department
 Abbreviation codes are alphabetic abbreviations
 State codes include NY for New York, ME for Maine, and MN for
Minnesota
 Some abbreviation codes are called mnemonic codes
because they use a specific combination of letters that are
easy to remember

49
Should You Use Codes? (Cont.)

FIGURE 9-39 This image shows abbreviations

for the world’s 30 busiest airports. How many
can you identify? 50
 Should You Use Codes? (Cont.)

 Types of Codes (Cont.)

◦ Significant digit codes

 Distinguish items by using a series of subgroups of digits
 Postal codes are significant digit codes
◦ Derivation codes
 Combine data from different item attributes, or characteristics
◦ Cipher codes
 Use a keyword to encode a number
 A retail store, for example, might use a 10-letter word, such as
CAMPGROUND, to code wholesale prices, where the letter C
represents 1, A represents 2, and so on. Thus, the code, GRAND,
indicates that the store paid $562.90 for the item
◦ Action codes
 Indicate what action is to be taken with an associated item
 X (to exit the program)

51
 Should You Use Codes? (Cont.)

FIGURE 9-40 Sample of a code that uses significant digits to pinpoint the location of an
inventory item

FIGURE 9-41 A magazine subscriber code is derived

from various parts of the name and address 52
 Should You Use Codes? (Cont.)

 Designing Codes
◦ Keep codes concise
◦ Allow for expansion
◦ Keep codes stable
◦ Make codes unique
◦ Use sortable codes
◦ Use a simple structure
◦ Avoid confusion
◦ Make codes meaningful
◦ Use a code for a single purpose
◦ Keep codes consistent
53
 Data Storage and Access
 Tools and Techniques
◦ Companies use data warehousing and data
mining as strategic tools to help manage the
huge quantities of data they need for business
operations and decisions
◦ Data warehousing
◦ Data mining

54
 Data Storage and Access (Cont.)

 Data Warehousing
◦ An integrated
collection of data
that can include
seemingly unrelated
information, no
matter where it
is stored in
the
company

FIGURE 9-42 A data warehouse stores data from several systems. By

selecting data dimensions, a user can retrieve specific information
without having to know how or where the data is stored
55
 Data Storage and Access (Cont.)

 Data Mining
◦ Looks for
meaningful
data patterns and
relationships in
large amounts
of data

FIGURE 9-43 North Carolina State

University’s clickable map can take you to
a collection of IT ethics issues. Here, the
map points to the data mining area

56
 Data Storage and Access (Cont.)

 Logical versus Physical Storage

◦ Logical storage refers to data that a user can
view, understand, and access, regardless of
how or where that information actually is
organized or stored
◦ Physical storage is strictly hardware-related
because it involves the process of reading and
writing binary data to physical media such as a
hard drive, CD-ROM, or network-based storage
device

57
 Data Storage and Access (Cont.)

 Data Coding
◦ EBCDIC (Extended Binary Coded Decimal
Interchange Code - pronounced EB-see-dik)
 A coding method used on mainframe computers
and high-capacity servers
◦ ASCII (American Standard Code for Information
Interchange - pronounced ASK-ee)
 A coding method used on most personal
computers
◦ BINARY
 Represents numbers as actual binary values,
rather than as coded numeric digits

58
 Data Storage and Access (Cont.)

 Data Coding (Cont.)

◦ UNICODE
 Supports virtually all languages and has become a
global standard

FIGURE 9-44 Unicode is an international coding format that

represents characters as integers, using 16 bits per character.
The Unicode Consortium maintains standards and support for
Unicode 59
 Data Storage and Access (Cont.)

 Data Coding (Cont.)

◦ STORING DATES
 Y2K Issue
 International
Organization for
Standardization (ISO)
requires a
format of four digits
for the year, two for
the month, and two FIGURE 9-45 Microsoft Excel uses absolute dates in
for the day calculations. In this example, September 27, 2013, is
(YYYYMMDD) displayed as 41544, and July 13, 2012, is displayed as
41103. The difference between the dates is 441 days

60
 Data Control
 A well-designed DBMS must provide built-
in control and security features, including
subschemas, passwords, encryption, audit
trail files, and backup and recovery
procedures to maintain data

61
Chapter Summary
 A database consists of linked tables that
form an overall data structure
 A database management system (DBMS) is a

collection of tools, features, and interfaces

that enable users to add, update, manage,
access, and analyze data in a database
 DBMS designs are more powerful and flexible

than traditional file-oriented systems

62
Chapter Summary (Cont.)

 DBMS components include interfaces for users,

database administrators, and related systems; a
data manipulation language; a schema; and a
physical data repository
 In an information system, an entity is a person,

place, thing, or event for which data is collected

and maintained
 A primary key is the field or field combination

that uniquely and minimally identifies a specific

record; a candidate key is any field that could
serve as a primary key

63
Chapter Summary (Cont.)

 An entity-relationship diagram (ERD) is a graphic

representation of all system entities and the
relationships among them
 The relationship between two entities also is
referred to as cardinality
 Normalization is a process for avoiding problems in
data design
 Data design tasks include creating an initial ERD;
assigning data elements to an entity; normalizing all
table designs; and completing the data dictionary
entries for files, records, and data elements

64
Chapter Summary (Cont.)

 A code is a set of letters or numbers used to

represent data in a system
 Logical storage is information seen through a

user’s eyes, regardless of how or where that

information actually is organized or stored
 Physical storage is hardware related and involves

reading and writing binary data to physical media

 File and database control measures include

limiting access to the data, data encryption,

backup/recovery procedures, audit-trail files,
and internal audit fields

65