DFD

A Data Flow Diagram is a picture of the movement of data between external entities and the processes and data stores within a system. Systems analysts use data flow diagrams to help them model the processes internal to an information system and how data from the systems environment enter the system, are used by the system, and are returned to the environment.

DFDs help analysts understand how the organization handles information.

Data Flow Diagramming Mechanics DFDs are flexible diagramming tools. With only four (4) simple symbols, you can use data DFDs to represent both physical and logical information systems.

There two different standard sets of DFD symbols, but each set consists of four symbols that represent the same things: data flows, data stores, processes/actions, and sources/sinks (or external entities).

A Data Flow can be best understand as data in motion, moving from one place in a system to another. A Data Store is data at rest (files, folders, etc.). A Data Process is the work or actions performed on data so that they are transformed, stored, and/or distributed. A Data Source is the origin and/or destination of data, sometimes referred to as external entities.

Data Flow Diagram Notations

You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane & Sarson.

Process Notations

Process
A process transforms incoming data flow into outgoing data flow.

Yourdon and Coad Process Notations

Gane and Sarson Process Notation

Datastore Notations

Data Store Data stores are repositories of data in the system. They are sometimes also referred to as files.

Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations

Dataflow Notations

Dataflow

Data flows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through it.

External Entity Notations

External Entity External entities are objects outside the system, with which the system communicates. External entities are sources and destinations of the system's inputs and outputs.

Data Flow Diagramming Rules

1) Processes cannot have only outputs, cannot have only

inputs, and must have a verb phrase label. 2) Data can only move to a data store from a process. 3) Similarly, data can only be moved to an outside sink or to another data store by a process. 4) Data to and from external sources and sinks can only be moved by processes.

5) Data flows move in one direction only. 6) Both branches of a forked or a joined data flow must represent the same type of data.

7) A data flow cannot return to the process from which it originated.

8) No process can have only outputs or only inputsprocesses must have both outputs and inputs.

Data store labels should be noun phrases. All flows to or from a data store must move through a process.

No data moves directly between external entities without going through a process. Source and sink labels should be noun phrases.

Bidirectional flow between process and data store is represented by two separate arrows. Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.

Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location. Data flow cannot go directly from a process to itself, must go through intervening processes.

a) Improperly Drawn DFD

(b) Proper Use of a Process

Context Diagrams A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudo code.

What are Entity Relationship Diagrams? Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.

Entity Relationship Diagram Notations

Peter Chen developed ERDs in 1976. Since then Charles Bachman and James Martin have added some sligh refinements to the basic ERD principles. Entity An entity is an object or concept about which you want to store information.

Key attribute A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.

Multivalued attribute A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values. Derived attribute A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.

Relationships Relationships illustrate how two entities share information in the database structure.