PAATAN, Ivory P.

BSAC 3 11:30- 12:30 MWF

Data Flow Diagram(DFD)

I. Overview:
A data flow diagram is a modelling technique for structuring and examining information
processes excellent as a communication tool.
It is a visual presentation supporting the course and movement of information in a process. It
shows classification of information of the input and the output, the movement of data between
external entities and the processes and data storage. It does not include information about the
timing of processes, or information about whether processes will operate in sequence or in
parallel (which is shown on a flowchart).
The basic DFD is the context-level which shows the relationship between the entities inside
and outside of a system as one single step. This basic DFD can be then broken down to a lower
level diagram demonstrating smaller levels to show details of the system modelled. Number of
levels would mean more complicated system.
It was introduced and was popularized for structured analysis and design (Gane and Sarson
1979).

II. Concepts:

Process:
It transforms incoming data flow into outgoing data flow. Represented by rectangular boxes
with top stripe that contains an identification number in the left, and the location (or the role
carrying out the work) on the right (this is optional and used only in the current physical DFD).
*Labels should be verb phrases

Data: Is a path for data to move from one part of the IS to another
Represented by arrows depicting movement of data
Can represent flow between process and data store by two separate arrows
Data stores: These are storage of data (permanent or temporary) in the system. Sometimes
referred to as files. It may be a card index, a database file, a temporary pile of sales, or a folder
in a filing cabinet.
*Labels should be noun phrases

Source/Sink (External Entity): External entities are objects outside the system that the system
communicates. External entities are sources and destinations of the system's inputs and
outputs.
*Labels should be noun phrases
 A. Conventions
1. Legal and illegal data flow- All data flows must begin and/or end with a process. In a legal
data flow, data from a source should pass through an intermediate process before going to the
destination. While for an illegal data flow, data is directly transferred from a source to the
destination.
2. Data flow lines- Two data flow lines or arrow is used to show multiple data flows. Multiple
data flows occur when output and input data flows are different.
3. Naming- Naming a symbol consists of a verb followed by a noun. For sources, destinations,
and data stores, names are capitalized, while process names and data flows are shown mixed
case.
4. Numbering- As a reference, level 1 data flow diagram processes are numbered as 1, 2, 3 and
so on. The sub-processes in an exploded data flow diagram are assigned numbers starting
with the parent processs number.
5. Duplicate symbols- For easier diagram reading, symbols can be duplicated. Duplicate
symbols are usually marked in some way.

B. Underlying principles
1. The principle of data conservation-
All concepts are used efficiently. A process is bound not to lose or create data. Any data
must be used by or output by that process. An output must be created by an algorithm within
the process. And data created by an algorithm can be used by another algorithm within the
same process or output by the process. Except for constant data, which should first flow into
the process before used by an algorithm.
2. The principle of iteration-
High-level processes are decomposed into lower-level processes. At the lowest level are
primitive processes that perform a single function (or algorithm). Inputs and outputs from
higher level process must be reflected in lower-level (decomposed) processes. These may
be described in greater detail in the lower- level diagram
C. Levels
1. The context (level 0) diagram- A context (level 0) diagram documents the systems
boundaries by highlighting its sources and destinations. Documenting the systems
boundaries by drawing a context diagram helps the analyst, the user, and the responsible
managers visualize alternative high-level logical system designs.
2. The level 1 data flow diagram- A level 1 data flow diagram shows the systems primary
processes, data stores, sources, and destinations linked by data flows. Generally, a systems
primary processes are independent, and thus, separated from each other by intermediate data
stores that suggest the data are held in some way between processes.
3. Other levels- Each level 1 process consists of several sub-processes that are listed on the
process description. To explode the data flow diagram, the analyst creates an independent
level 2 data flow diagram for each level 1 process.

III. Symbols:
Using the Gane and Sarson notation. There are only four symbols:
1. Squares representing external entities, which are sources or destinations of data.
2. Rounded rectangles representing processes, which take data as input, do something to it, and
output it.
3. Arrows representing the data flows, which can either be electronic data or physical items.
 4. Open-ended rectangles representing data stores, including electronic stores such as
databases or XML files and physical stores such as or filing cabinets or stacks of paper.

IV. Rules in making:

One system may be disintegrated into subsystems, which in turn can be disintegrated into
subsystems at a much lower level, and so on and so forth. Every subsystem in a DFD
represents a process. In this process or activity the input data is processed. Processes cannot
be decomposed after reaching a certain lower level. Each process in a DFD characterises an
entire system. In a DFD system, data is introduced into the system from the external
environment. Once entered the data flows between processes. And then the processed data is
produced as an output or a result.

Rule 1: All Processes must have at least one outgoing data flow or at least one incoming data
flow
Rule 2: All processes can connect to any other symbol (including another process symbol). All
processes should modify the incoming data, producing new forms of outgoing data.
Rule 3: Each data store must be involved with at least one data flow.
Rule 4: Each external entity must have at least one incoming and one out going data flow
Rule 5: A data flow must be connected to a process by a data flow

V. References:
Prateek Kanther. Data flow diagram, Retrieved from: http://www.scribd.com/doc/37516151/ Data-Flow-Diagram
Hendon. 1997. Data flow diagrams. Retrieved from: http://www.eis.mdx.ac.uk/staffpages/geetha/bis2030/DFD.html

Scott W. Ambler. 2009 . Data Flow Diagrams. Retrieved from: http://www.agilemodeling.com/artifacts/dataFlow

Diagram.htm

Jay Gould, Data flow diagram concepts, retrieved from: http://www.docstoc.com/docs/4211167/Data-Flow-Diagram-

Concepts

William S. Davis, David C. Yen. The Information System Consultant's Handbook: Systems Analysis and Design. Data
flow diagrams. Ch.24. Retrieved from: http://www.hit.ac.il/staff/leonidM/information-systems/ch24.html
 Data dictionary (DD)

A data dictionary is a compilation of defined data objects or items in a data model for the
benefit of programmers and others who need to refer to them. Data dictionaries do not contain
any actual data from the database, only bookkeeping information for managing it. Without a
data dictionary, however, a database management system cannot access data from the
database.

I. It contains:
The definitions of all objects in the database (tables, views, indexes, clusters, synonyms,
sequences, procedures, functions, packages, triggers, and so on)
How much space has been allocated for, and is currently used by, the schema objects
Default values for columns
Integrity constraint information
The names of Oracle Database users
Privileges and roles each user has been granted
Auditing information, such as who has accessed or updated various schema objects
Other general database information

II. Facility

Conceptual data models (entities, attributes, relationships)

To record and analyse data requirements independently of how they are going to be met
Internal schema
To record and design decisions in terms of database or file structures implemented and the
programs which access them.

III. Advantages of having DD:

improve control and knowledge about the data resource.
allows accurate assessment of cost and time scale to effect any changes.
reduces the clerical load of database administration, and gives more control
over the design and use of the database.
accurate data definitions can be provided securely directly to programs.
aid the recording, processing, storage and destruction of data and associated documents.
generate test files and documentation.
enforce standards on programming, improving readable and consistency.
aid application maintenance because changes to the data and the data structures can be
made automatically to all programs using the data.
aid the operations side of computing by holding details of storage, recovery procedures, and
archiving information.
provide security features such as passwords to assist in the protection of the data resource.

IV. Disadvantages of having DD:

The DDS project may itself take two or three years.
It needs careful planning, defining the exact requirements designing its contents, testing,
implementation and evaluation.
 The cost of a DDS includes not only the initial price of its installation and any hardware
requirements, but also the cost of collecting the information entering it into the DDS, keeping it
up-to-date and enforcing standards.
The use of a DDS requires management commitment, which is not easy to achieve,
particularly where the benefits are intangible and long term.

V. Steps:
1. Modeling- Identify each object and its relationship to other objects.
2. Describe each data object identified according to its relationship to other objects and type of
data it contains.

VI. Data Types

References:

Data dictionary. Retrieved from: http://www.webopedia.com/TERM/D/data_dictionary.html

Oracle Database concepts. Retrieved from: http://docs.oracle.com/cd/B28359_01/server.111/b28318/datadict.htm

Margaret Rouse. 2005. Data dictionary. Retrieved from: http://searchsoa.techtarget.com/definition/data-dictionary

Data Dictionary Guide. Retrieved from: http://wiki.alfresco.com/wiki/Data_Dictionary_Guide

Gordon Russel. Data dictionary. Retrieved from: http://db.grussell.org/resources/pdf/Data%20Dictionary.pdf