34
Copyright © 2016 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education. Chapter 7 Data Flow Diagramming

Sppt chap007

Embed Size (px)

Citation preview

Page 1: Sppt chap007

Copyright © 2016 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.

Chapter 7

Data Flow Diagramming

Page 2: Sppt chap007

7-2

Outline

• Learning objectives• Nature and purpose of DFDs• DFD symbols• Leveling and balancing• Database design• Normal forms

Page 3: Sppt chap007

7-3

Learning objectives

1) Explain the symbols and design considerations associated with DFDs.

2) Compare and contrast flowcharts and DFDs with regard to purpose, content, structure, and use in accounting information systems.

3) Discuss ways DFDs are used in AIS work.

4) Construct a leveled set of DFDs.

5) Design normalized database tables from a DFD.

Page 4: Sppt chap007

7-4

Nature and purpose of DFDs

• Not as widely used as flowcharts in accounting practice

• Two main purposes– Understanding a business process– Understanding the relational database that

underlies the AIS

• Focus on data

Page 5: Sppt chap007

7-5

DFD symbols

process

external entity

data flow

data store

Page 6: Sppt chap007

7-6

DFD symbols

customer order

1.0Take customer

ordercustomer

order database

Page 7: Sppt chap007

7-7

Leveling and balancing

• Data flow diagrams are prepared in leveled sets.

• Each level reveals more detail than the one before it.

• Levels must be balanced, which means that external entities and data flows at the boundary cannot “disappear” between levels.

Page 8: Sppt chap007

7-8

Leveling and balancing

• Level names– Context diagram

– Level Zero diagram

– Level One diagrams

– Level Two diagrams

– And so on. . .

Page 9: Sppt chap007

7-9

Leveling and balancing• Context diagram

• Highest level view of the system

• Exactly one in a leveled set

• Exactly one process

• One or more external entities

• No data stores

Customer

0Order taking

process

Customerorder

Invoice

Page 10: Sppt chap007

7-10

Leveling and balancing• Level Zero

diagram• Exactly one in a

leveled set• More detail than

the context diagram

• Preserve data flows at the boundary

Customer

Customerorder

Invoice

1.0Process customer

order.

2.0Bill customer.

Processed customerorder

Page 11: Sppt chap007

7-11

Leveling and balancing• Level One diagram

• May be more than one in a leveled set

• More detail than the Level Zero diagram

• Each Level One focused on a single “bubble” from Level Zero

• Preserve data flows at the boundary

See the example on

the next slide,

which “explodes”

Process 1.0

(Process customer

order) from the

Level Zero diagram.

Page 12: Sppt chap007

7-12

Leveling and balancing

Customer

Customerorder

1.1Verify

customer order. Verified

customerorder

1.2Evaluate customer

credit.

Customer database

Creditinquiry

Creditdecision

Processed customer order

Page 13: Sppt chap007

7-13

Leveling and balancing

• Processes are decomposed (“exploded”) until they are primitive.

• Processes may be decomposed to different levels.

• Numbering conventions– Level One diagram of Process 2.0: 2.1, 2.2– Level Two diagram of Process 1.2: 1.2.1,

1.2.2

Page 14: Sppt chap007

7-14

Database design

• Objects

• Terminology

• Normal forms

Page 15: Sppt chap007

7-15

Database design

• Objects: tables– Every relational database must include at

least one table.– Most will include multiple tables– Organization

• Fields (columns)• Records (rows)

– See the example on the next slide.

Page 16: Sppt chap007

7-16

Database design

Student table in design view

Student table in datasheet view

Page 17: Sppt chap007

7-17

Database design

• Objects: queries– Sets of instructions that examine current data

in tables and / or other queries– Output data according to the instructions– Can include simple computations (e.g., total,

average)– See the example on the next slide

Page 18: Sppt chap007

7-18

Database design

Query in design view

Query in datasheet view

Page 19: Sppt chap007

7-19

Database design

• Objects: forms– Allow a user to interact with a database even

if they know nothing about design and structure

– Two uses: data input, data lookup

– See the example on the next slide

Page 20: Sppt chap007

7-20

Database design

Form in design view Form in form view

Page 21: Sppt chap007

7-21

Database design

• Objects: reports– Well formatted output of a relational database

– Can be based on tables and / or queries

– Can incorporate simple calculations

– See the example on the next slide

Page 22: Sppt chap007

7-22

Database design

Report in report view(Design view not shown)

Page 23: Sppt chap007

7-23

Database design

• Terminology– Primary key: a field in a table that uniquely

identifies every record in that table– Foreign key: a primary key in one table that

is included in another table for linking purposes

– Compound primary key: two or more fields in a table that together comprise its primary key

Page 24: Sppt chap007

7-24

Database design

• TerminologyJunction table

• A table that joins together two separate tables.• Required when the two separate tables have a “many-

to-many” relationship– Every student may enroll in many classes.– Every class has many students.

• Named by joining the separate table names– Student table– Class table– Student / class table

• See the illustration on the next slide

This is the junction table.

Page 25: Sppt chap007

7-25

Database design

Relationship grid

Page 26: Sppt chap007

7-26

Database design

• Normal formsTable characteristics that ensure a relational database is organized as efficiently and effectively as possible

• Minimize space allocations

• Facilitate searches

• Establish relationships between tables

Page 27: Sppt chap007

7-27

Database design

• First normal form (1NF)– Eliminates repeating

groups• Second normal form

(2NF)– Eliminates repeating

groups– Eliminates redundant

data

• Third normal form (3NF)– Eliminates repeating

groups– Eliminates redundant

data– Eliminates columns

not dependent on the primary key

Page 28: Sppt chap007

7-28

Database design

• The next few slides show you how to start with a

“flat file” (such as a spreadsheet) and create

normalized database tables.

• With practice, you’ll be able to design normalized

tables “from scratch.”

• The following example is drawn from the 23

January 2014 post on Dr. Hurt’s AIS blog.

Page 29: Sppt chap007

7-29

Normal forms

This data array is a “flat file” comprising two fields and

five records. It is not normalized, as the “courses”

field includes repeating groups of data (i.e., two

courses in one field).

Student ID Courses1026 Acc 343, Psy 2001053 Acc 343, Eng 1171221 Bus 281, Mat 1461270 Acc 343, Eng 1171397 Bus 281, Psy 200

Page 30: Sppt chap007

7-30

• To put the array in 1NF, we need to eliminate repeating groups.

Normal forms

Student ID Prefix Number Prefix Number1026 Acc 343 Psy 2001053 Acc 343 Eng 1171221 Bus 281 Mat 1461270 Acc 343 Eng 1171397 Bus 281 Psy 200

Course 1 Course 2

This array, while not fully normalized, is closer to

that state. Note that we could search for specific

course prefixes and / or numbers more easily than in

the flat file.

Page 31: Sppt chap007

7-31

• To put the data in 2NF, we need to eliminate redundant data.

Normal forms

Student tableStudent ID

10261053122112701397

Prefix NumberAcc 343Bus 281Psy 200Eng 117Mat 146

Course table

Neither table has repeating groups or redundant data;

however, we’re missing key information: which

students are in which courses?

Page 32: Sppt chap007

7-32

• Junction table– Completes 2NF by

marrying data from two other tables

– Requires a compound primary key

– Many-to-many relationship

• Each student can take many courses.

• Each course can have many students.

Student ID Prefix Number1026 Acc 3431026 Psy 2001053 Acc 3431053 Eng 1171221 Bus 2811221 Mat 1461270 Acc 3431270 Eng 1171397 Bus 2811397 Psy 200

Student / course table

Normal forms

Page 33: Sppt chap007

7-33

• To put the data in 3NF, we must ensure that each table contains only fields that give us more information about the primary key.– Student table: last name, first name, area code,

phone number– Course table: course title, instructor, building,

classroom, section number– Student / course table: probably does not need

any information beyond the primary keys of the two other tables

Normal forms

Page 34: Sppt chap007

7-34