Chapter 6

Data Design

2

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 architecture

3

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)

4

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

design

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

Data Design Concepts

Overview of Database Systems

13

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

14

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

15

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

16

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

17

DBMS Components Data Manipulation Language

A data manipulation language (DML) controls database operations, including storing, retrieving, updating, and deleting data

18

Data Design Terminology Definitions

Entity Table or file Field

Attribute - Common field Record

Tuple

19

Data Design Terminology Key Fields

Primary key Combination key Composite key Concatenated key Multi-valued key

Candidate key Nonkey field

Foreign key Secondary key

20

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

21

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

22

Data Relationships Entity-Relationship Diagrams

23

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)

24

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

25

Normalization

Repeating Groups and Unnormalized Design Repeating group - Often occur in

manual documents prepared by users Unnormalized design

26

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

27

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

28

Normalization

Second Normal Form A standard process exists for

converting a table from 1NF to 2NF1. Create and name a separate table for

each field in the existing primary key2. Create a new table for each possible

combination of the original primary key fields

3. Study the three tables and place each field with its appropriate primary key

29

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

30

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

31

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

32

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

33

Steps in Database Design

1. Create the initial ERD2. Assign all data elements to entities3. Create 3NF designs for all tables,

taking care to identify all primary, secondary, and foreign keys

4. Verify all data dictionary entries After creating your final ERD and

normalized table designs, you can transform them into a database

34

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

35

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 data

36

Data Control

User ID Password Backup Recovery procedures Audit log files Audit fields Encryption

37

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

38

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

39

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

40

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