Transcript Chapter 6 Instructor Slides

Chapter 6
Data Design
Design Phase Description



Systems Design is the third of five
phases in the systems development life
cycle (SDLC)
Begin the physical design of the IS that
meet the specifications described in the
system requirements document
IS design tasks include data design,
user interface design, and system
2
architecture
Chapter Objectives



Explain data design concepts and data
structures
Describe file processing systems and
various types of files
Understand database systems and
define the components of a database
management system (DBMS)
3
Chapter Objectives




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
Explain the concept of normalization
Understand the steps in database
4
design
Chapter Objectives




Describe hierarchical, network,
relational, and object-oriented database
models
Explain data warehousing/data mining
Differentiate between logical and
physical storage and records
Explain data control measures
5
Introduction



Develop a physical plan for data organization,
storage, and retrieval
Begins with a review of data design concepts
and terminology, then discusses file-based
systems and database systems, including
Web-based databases
Concludes with a discussion of data mining,
data warehousing, physical design issues,
logical and physical records, data storage
formats, and data controls
6
Data Design Concepts

Before constructing an IS, a systems
analyst must understand basic design
concepts, including data structures and
the characteristics of file-oriented and
database systems
7
Data Design Concepts

Data Structures




A file or table contains data about people,
places or events that interact with the
system
File-oriented system
File processing
Database system
8
Data Design Concepts

Overview of File Processing


Some companies use file processing to
handle large volumes of structured data
Although less common today, file
processing can be more efficient and cost
less than a DBMS in certain situations
9
Data Design Concepts

Overview of File Processing

Potential problems




Data redundancy
Data integrity
Rigid data structure
Uses various types of files






Master file
Table file
Transaction file
Work file – scratch file
Security file
History file
10
Data Design Concepts

Overview of Database Systems


A properly designed database system
offers a solution to the problems of file
processing
Provides an overall framework that avoids
data redundancy and supports a real-time,
dynamic environment
11
Data Design Concepts

Overview of Database Systems
12
Data Design Concepts

Overview of Database Systems


A database management system (DBMS) is
a collection of tools, features, and
interfaces that enables users to add,
update, manage, access, and analyze the
contents of a database
The main advantage of a DBMS is that it
offers timely, interactive, and flexible data
access
13
Data Design Concepts

Overview of Database Systems

Advantages










Scalability
Better support for client/server systems
Economy of scale
Flexible data sharing
Enterprise-wide application – database administrator (DBA)
Stronger standards
Controlled redundancy
Better security
Increased programmer productivity
Data independence
14
Data Design Concepts

Database Tradeoffs



Because DBMSs are powerful, they require
more expensive hardware, software, and
data networks capable of supporting a
multiuser environment
More complex than a file processing
system
Procedures for security, backup, and
recovery are more complicated and critical
15
DBMS Components

Interfaces for Users, Database
Administrators, and Related Systems

Users




Query language
Query by example (QBE)
SQL (structured query language)
Database Administrators

A DBA is responsible for DBMS management
and support
16
DBMS Components

Data Manipulation Language

A data manipulation language (DML)
controls database operations, including
storing, retrieving, updating, and deleting
data
17
Data Design Terminology

Definitions




Entity
Table or file
Field
 Attribute - Common field
Record
 Tuple
18
Data Design Terminology

Key Fields

Primary key





Candidate key



Combination key
Composite key
Concatenated key
Multi-valued key
Nonkey field
Foreign key
Secondary key
19
Data Design Terminology

Referential Integrity


Validity checks can help avoid data input
errors
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
20
Steps to Build Database








Understand and list business rules
Define major processes
Define information components
Assign all data elements to the entities
Develop ER model
Define cardinality and keys
Identify all dependencies
Normalize the entities
21
Data Relationships Entity-
Relationship Diagrams
22
Data Relationships


A relationship is a logical link between entities
based on how they interact
Entity-Relationship Diagrams




One-to-one relationship (1:1)
One-to-many relationship (1:M)
Many-to-many relationship (M:N)
Cardinality



Cardinality notation
Crow’s foot notation
Unified Modeling Language (UML)
23
Normalization




Normalization
Table design
Involves four stages: unnormalized
design, first normal form, second
normal form, and third normal form
Most business-related databases must
be designed in third normal form
24
Normalization

Repeating Groups and Unnormalized
Design


Repeating group - Often occur in manual
documents prepared by users
Unnormalized design
25
Normalization

First Normal Form


A table is in first normal form (1NF) if it does not
contain a repeating group
To convert, you must expand the table’s primary
key to include the primary key of the repeating
group
26
Normalization

Second Normal Form


To understand second normal form (2NF),
you must understand the concept of
functional dependence
Field X is functionally dependent on field Y
if the value of field X depends on the value
of field Y
27
Normalization

Second Normal Form
A standard process exists for converting
a table from 1NF to 2NF

1.
2.
3.
Create and name a separate table for each
field in the existing primary key
Create a new table for each possible
combination of the original primary key
fields
Study the three tables and place each field
with its appropriate primary key
28
Normalization

Second Normal Form

Four kinds of problems are found with 1NF
description that do not exist with 2NF




Consider the work necessary to change a
particular product’s description
1NF tables can contain inconsistent data
Adding a new product is a problem
Deleting a product is a problem
29
Normalization

Third Normal Form


3NF design avoids redundancy and data integrity
problems that still can exist in 2NF designs
A table design is in third normal form (3NF) if it is
in 2NF and if no nonkey field is dependent on
another nonkey field
30
Normalization

Third Normal Form

To convert the table to 3NF, you must
remove all fields from the 2NF table that
depend on another nonkey field and place
them in a new table that uses the nonkey
field as a primary key
31
Normalization

A Normalization Example


To show the normalization process, consider the
familiar situation in Figure 6-24 which might
depict several entities in a school advising system:
ADVISOR, COURSE, and STUDENT
The relationships among the three entities are
shown in the ERD in Figure 6-25
32
Steps in Database Design
1.
2.
3.
4.

Create the initial ERD
Assign all data elements to entities
Create 3NF designs for all tables,
taking care to identify all primary,
secondary, and foreign keys
Verify all data dictionary entries
After creating your final ERD and
normalized table designs, you can
transform them into a database 33
Data Storage

Data Warehousing



Data warehouse - dimensions
Without a data warehouse it would be
difficult for a user to extract data that spans
several information systems and time frames
Allows users to retrieve and analyze the
data easily
34
Data Control


File and database control must include
all measures necessary to ensure that
data storage is correct, complete, and
secure
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
35
Data Control







User ID
Password
Backup
Recovery procedures
Audit log files
Audit fields
Encryption
36
Chapter Summary


Files and tables contain data about
people, places, things, or events that
affect the information system
DBMS designs are more powerful and
flexible than traditional file-oriented
systems
37
Chapter Summary


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
The four basic database models are
hierarchical, network, relational, and
object-oriented
38
Chapter Summary


Physical storage is hardware-related and
involves reading and writing blocks of 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
39
Review: Analysis Phase

Deliverable – Systems Requirement
Document





Fact-finding of current system and identify system
requirements
Develop logical model (WHAT IS must do)
Develop physical model (HOW IS is constructed)
Evaluate development strategies
Create the System Requirement Document
40