Paper 6: Management Information System

Module 26: System Design (DFD & ER Diagrams)

Prof. S P Bansal
Principal Investigator Vice Chancellor
Maharaja Agrasen University, Baddi

Prof Yoginder Verma

Co-Principal Investigator Pro–Vice Chancellor
Central University of Himachal Pradesh. Kangra. H.P.

Prof. Manu Sood

Paper Coordinator Chairman, Department of Computer Science,
H.P University, Summer Hill, Shimla.
.
Ms. Vinodini Kapoor
Content Writer Asst. Prof, Northern India Institute of Fashion Technology
Mohali, India
 Items Description of Module
Subject Name Management
Paper Name Management Information System
Module Title System Design (DFD & ER Diagrams)
Module Id Module No.-26
Pre- Requisites A basic overview of system analysis and design and its importance in MIS
Objectives To understand the concept of system design via DFD and ER diagrams
Keywords Entity, attribute, cardinality, ordinality, relationship

QUADRANT-I

Module-26 System Design (DFD & ER Diagrams)

1. Learning Outcome
2. Introduction
3. Concept of System Design
3.1 Conceptual Design
3.2 Detailed Design
3.3 Differences between Conceptual and Detailed Design
4. Data Flow Diagrams
4.1 Data Flow Diagrams Symbols and Notations
4.2 Food Ordering System Example
5. Entity Relationship Diagrams
5.1 Entity Relationship Diagrams Symbols and Notations
5.2 Building Effective ER Diagrams
6. Differences Between DFD and ER Diagrams
7. Summary

1. Learning Outcome:
After completing this module the students will be able to:
 Understand the basic concept of System Design
 Understand System Design via use of Data Flow Diagrams and Entity Relationship Diagrams
 List various symbols and notations for DFD and ER Diagrams.
 Understand applications of DFD and ER Diagrams.
 Understand differences between DFD and ER Diagrams.

2. Introduction
“A picture is worth a thousand words.” A common idiom that suggests that an image is more expressive
than the description would be. Similarly, a Data Flow Diagram (DFD) is traditional visual representation
of the information flows within a system. A clear DFD can depict a good quantum of system
requirements graphically. It can be manual, automated, or combination of both. It shows how information
enters and leaves the system, what changes the information and where information is stored. The concept
of a DFD is to outline the boundary of a system as a whole. It may be used as a communications tool
between a systems analyst and any person who plays a part in the system that acts as the starting point for
redesigning a system.

Data flow diagramming is very effective technique for showing the flow of information through a system.
They are used in the initial stages of systems analysis to help estimate the current system and to represent
a required system. The DFDs determine the external entities sending and receiving information, the
processes that change information, the data flow and where the information is stored. DFDs are a form of
information development, and as such provide key insight into how information is transformed as it
passes through a system.

3. System Design

System Design stage gives answers to the question, “How” the system will accomplish the objective.
System Design consists of design activities that produce system specifications, satisfying the functional
requirements developed in the analysis stage. System Design consists of two steps, one is conceptual
design and other is detailed design of information system.

3.1 Conceptual Design

Conceptual Design represents the structure of Management Information System. It takes input from
statement of management information requirement and management objective for the management
information system. The output of this stage is the performance requirement of those who will develop
the detailed design. The features of the new system are specified. The costs of implementing these
features and the benefits to be derived are estimated and if feasible, the detailed design is commenced.

Conceptual design serves as the underlying criteria to formulate the detailed MIS design. The
requirements specified by the conceptual design become inputs to the detailed design phase, in which
these are detailed to be called the system specifications.

3.2 Detailed Design

This stage organizes the system in astructured format, highlighting the various components and
interrelationships between components. Details regarding the various inputs, output, databases, schemas,
codes and processing specifications are drawn up in detail. Further, the programming language, the
hardware and the software platform are also decided.

In order to make the detailed design, first of all, the system designers need to have consensus with the
concerned stakeholders. It is essential to involve them in the designing process. The designer works
along with the task force, the intermediate level manager and a selected group of operating staff to study
the internal and external source documents. The detailed design is essential in designing the user
interface, data design and process design.
3.3 Difference between Conceptual and Detailed Design

Conceptual design gives the overall performance specification of Management Information System, and
the detailed design discusses construction and operating specifications. The broad differences are:

1. Conceptual design gives a holistic structure and overall performance specification while the detailed
design gives operational and construction specification.
2. The input of the conceptual design is statement is the objective of Management Information System
while the input of detailed design is conceptual design report.
3. Conceptual design ends from where detailed designing of the proposed system starts so conceptual
design provides the base to detailed design i.e the output of conceptual design is used in detailed design.
4. Conceptual design provides the structure while the detailed design makes the structure to be
operational.

4. Data Flow Diagrams

In order to outline how information flows through systems (and how that data is transformed in the
process), data flow diagrams (DFDs) are the method of choice primarily because:

 DFDs are easier to interpret and understand.

 DFDs provide a high level system overview, stating boundaries and interconnections to other
systems.
 DFDs provide a representation of components.
 DFDs help system designers and others during initial analysis to visualize system or to meet new
requirements.
 Systems analysts require a vivid picture of the existing and postulated systems and refer to DFDs.

DFDs represent the following:

 All external devices for sending and receiving data.

 Processes involved in data changes.
 Data flow and data storage locations.
 A data flow diagram can be used to show the flow of information between the different
components of a management information system.
Exhibit 1: Representing the Data Flow
Image Source: https://realtimeboard.com/static/images/page/examples/detail/data-flow-diagram.png

4.1 Data Flow Diagrams Symbols and Notations

DFDs consist of four basic components that illustrate how data flows in a system: entity, process, data
store, and data flow as shown in Fig 1.

Symbol Meaning
An entity. A source of data or a destination for
Data.

A process or task that is performed by the

System.

A data store. A place where data is held between

processes.

A data flow.

Fig1. DFD Symbols & Notations

These can be explained as under:

 Entity - An entity depicts the source or destination of data. The source in a DFD represents
entities that lie beyond the context of the system. Entities may provide data to the system or
 receive data from it. Entities are represented as rectangles (a diagonal line across the right-hand
corner means that this entity is represented somewhere else in the DFD). Entities are also referred
to as terminators, or source/sink.

 Process - The process performs various functions on data, performs operations and directs the
flow of data based on conditions. In other words, a process receives input and generates some
output. Processes carry simplified names such as “Make Payment” highlighting the task to e
performed in a manual or automated way. These can be drawn as circles or a segmented
rectangle on a DFD, and include a process name and process number.

 Data Store - Data store is where a process stores data for retrieval at later stages by certain
process. To simplify, a files or table can be considered as a data store. Data store names can be
“customers, “products.” Data stores are usually drawn as a rectangle with the right hand side
missing and labeled by the name of the data storage area it represents, though different notations
do exist.

 Data Flow - Data flow determines the movement of data between the entities and processes and
the data stores. Data flow depicts the integration and the interface between the components of the
DFD. The flow of data is named to state the nature of the data used (these names should also be
unique within a specific DFD). Data flow is represented by an arrow, where the arrow is specified
with the data name.

The diagram below shows the flow of data when a management information system is used to produce a
summary report for company directors giving the weekly progress made by a manufacturer.

Management
Order Processing Sales Data File Information
System System

Stock Processing
Stock Data File Weekly Summary
System
Analysis Report

Credit Control Customer Data

System File

Fig2. Representing the DFD

4.2 The Food Ordering System

A context diagram is indicative of the top level or Level 0. At this stage, one process node highlights the
functions of a composite system with respect to its interaction with external entities.

Some of the benefits of a context diagram are:

 It depicts the boundaries of a system

 A technical expert is not required to interpret the simple notation
 These are simple to draw and elaborate as its limited notation

A context Data Flow Diagram for a Food Ordering System is represented below. It contains a process -
the "Food Ordering System”. The entities who will interact with the system are the supplier, kitchen,
manager and customer. The connectors between the process and the external entities indicate the
information exchange between the entities and the system.

Supplier

0. Food Ordering
Customer Kitchen
System

Manager

Source: https://www.visual-paradigm.com/tutorials/data-flow-diagram-
example-food-ordering-system.jsp
 Order
Customer 1. Order Food Kitchen
Bill
Inventory Details

Inventory Details
Reports
Inventory Generate Reports
Details
Manager

Inventory Order
Supplier Order Inventory

Inventory Order

Fig3 Food Ordering System DFD

It is observed from Fig 3 that the DFD comprises of three processes, four external entities and two data
stores. When a customer places an order, the Order Food process receives it and forwards it to the
Kitchen. The data is fed to the Order data store, and updated Inventory details in the Inventory data store.
The process also delivers a Bill to the Customer.

Manager obtains reports through the Generate Reports process, which takes Inventory and Orders as input
from data store respectively. The process forwards the Inventory order to the Supplier and stores the
updated Inventory details in the Inventory data store.

5. An Entity Relationship Diagram

An Entity Relationship diagram (ERD) is a technique depicting an information system’s entities and the
relationships between those entities. It is a conceptual model of data used to represent the entity
framework infrastructure.

The elements of an ERD are:

 Entities
 Relationships
 Attributes

ERD is essential for a good database design. It is used as a high level logical data model, which is useful
in developing a conceptual design for databases.
 An entity is a real world item that exists on its own. These are equivalent to database tables in a
relational database, where each row of the table is representing an instance of that entity.
 An attribute of an entity is a property that describes the entity.
  A relationship is the association that describes the interaction between entities. Cardinality
implies the number of instances of one entity that can, or must, be associated with each instance
of another entity. In general, there could be one to one, one to many, or many to many
relationships.

Considering two real world entities, a developer and his website. An individual has attributes such as a
name, designation, etc. Similarly, the visitor and developer can be defined. Similarly in case of a
department and employee, a department can interact with many employees, but an employee can belong
to only one department, hence there can be a one-to-many relationships.

Exhibit 3: ER Diagram Example

Image Source: http://www.studytonight.com/dbms/images/er-diagram.jpg

ER Diagrams

In the context of ER diagrams there are some elements which are derived from the main elements. They
are weak entity, multivalued attribute, derived attribute, weak relationship and recursive relationship.
Cardinality and ordinality are characteristics used in ER diagrams to further define relationships. ER
diagrams can relate to complex databases that are used in software engineering and IT networks.

The various components of ER diagrams are explained below:

 Entity - An entity can be stated to describe a noun such as a place, person, object or an event
associated with a given system. Entities are represented by a rectangle and named using singular
nouns.

 Weak Entity - A weak entity is derived from the main entity and depends on the existence of
another entity. In other words, it specifies an entity that cannot be identified by its own attributes.
An entity like order item is a good example for this. The order item will be meaningless without
an order so it depends on the existence of order.

The various symbols and notations are depicted in the Fig 4 below.
5.1 ER Diagram Symbols and Notations

Symbol Meaning
Entity

Attribute

Relationship

Weak Entity

Multivalued Attribute

Weak Relationship

Fig4. ER Diagram Symbols and Notations

Exhibit 4: Entity, Attributes and Relationship

Image Source: http://www.eazynotes.com/images/erd2.jpg

 Attribute - An attribute is a characteristic feature of an attribute. There may exist as many

attributes corresponding to a single entity. Attributes can also have their own specific attributes.
To exemplify, the attribute “customer address” can have the attributes number, street, city, and
state. These are called composite attributes. In certain ER diagrams, attributes are represented by
oval shapes.
 ID Customer Name

Address

Number City
Name

Fig5: Attribute Representation

 Multivalued Attribute –An attribute that can possess more than one value is called a multivalued
attribute. It is important to understand that this is different to an attribute having its own
attributes. For example a teacher entity can have multiple subject values.

Teacher Subjects

 Derived Attribute – This is the case of an attribute based on another attribute. This is found rarely
in ER diagrams.

Circle

Radius Area

 Relationship - A relationship describes how entities interact. For example, the entity “carpenter”
may be related to the entity “table” by the relationship “builds” or “makes”. Relationships are
represented by diamond shapes and are labeled using verbs.

Carpenter Makes Table

Fig8. Relationship between Entities

 Recursive Relationship - If the entity participates in more than one relationship it is known as a
recursive relationship. In the example stated below, if an employee can be a supervisor and also
be supervised, so there is a recursive relationship
 Supervision

Fig9. Recursive Relationship

Employee

ER diagrams are commonly used during the design stage of a development process in order to
identify different system elements and establish their relationships with each other.

 Connecting lines – These are solid lines that connect attributes to show the relationships of
entities in the diagram.
 Cardinality- This feature is indicative of the instances an entity can relate to another entity.
 Ordinality- This feature is also closely linked to cardinality. While cardinality specifies the
occurrences of a relationship, ordinality describes the relationship as either compulsory or
optional. It is an indication of the maximum number of relationships and ordinality specifies the
absolute minimum number of relationships.

The elements writer, novel, and consumer may be described using ER diagrams in the following way. In
the diagram, the elements inside rectangles are called entities while the items inside diamonds denote the
relationships between entities.

Writer Creates

Consumer Novel

Buys

ER Diagram with Basic Objects

Fig10. ER Diagram with basic objects

ER diagram Exemplified
Inventory software used in a retail shop will have a database that monitors elements such as items, item
type, item source and item price. Rendering this information through an ER diagram would be something
like shown in Fig 11 below.

Shopper Busy

Item type
Item

Item_price Item source

ER Diagram with Entity having Attributes

Fig11. ER Diagram with Entity having Attributes

5.3 Building effective ER Diagrams

An effective ER diagram should keep the following considerations in mind:

1. To identify all the relevant entities in a given system and determine the relationships among these
entities.
2. An entity should have the occurrence only once in a particular diagram.
3. It is essential to provide a precise and appropriate name for each entity, attribute, and relationship in the
diagram.
4. For the nomenclature, it is important to use simple terms than peculiar technical ones. It is essential to
distinguish similar yet distinct entities belonging to the same class (regular or part time worker).
Meanwhile, attribute names must be meaningful, unique, system-independent, and easily understandable.
5. It is essential to discard vague, redundant or unnecessary relationships between entities.
6. It is important to note that one relationship cannot be connected to another.
7. It is advisable to use colors effectively to highlight key areas in diagrams.
Exhibit 5: Simplified example of E-R Relationships
Image Source: http://www.umsl.edu/~sauterv/analysis/er/er_intro.html

6. Differences between DFD and ERD

DFD and ERD are different data models that are mainly used for organizing business data for proper
communication between members of a group.
 DFD shows how data enter a system, the transformation , and how it is stored in it. Meanwhile,
ERD represents the entity model and will show what a system or a database will look like but not
explain how to implement it.
 DFD and ERD follow different rules. With DFD, each of the processes and the storing should
have one data flow going towards it and one leaving it. All the data should traverse a certain
process, and all the processes should converge to some data store or another process. With ERD,
all the entities should represent a group of similar things. All the definitions in ERD should be
unambiguous.
 The DFD model is a representation with abstract information and includes multiple levels. The
ERD mode, on the other hand, represents the system data and includes an elaborate description of
the relation between the data.
 DFD is understood ovals, rectangles, or circles and is named with a single word. While, arrows
represent the flow, the ovals or parallel lines represent the storage. The ERD is represented by a
differently by a rectangular box, and diamonds represent the relationship between the entities.
Cardinality is represented by lines or standard notions.
 Both these data models have their own shortcomings. DFD may not completely describe a
system. Moreover, using symbols may create confusion in the mind of users. The DFD cannot
specify computations in a process. ERD does not show the interaction between the model and
data and how it changes in a system.

7. Summary
The main objectives of the system design stage are to determine specifications which can then be
converted into an information system for use in the organization. The design phase is a creative activity
determined by different levels of design, i.e. conceptual and detailed design. The conceptual design is also
termed as the feasibility design and navigates the MIS project and provides performance requirements.
The outputs of the conceptual design are specifications that serve as input to the detailed design to
produce specifications. The system specifications are conveyed to the programmer for translating into a
physical information system. These specifications, called the detailed or logical system design provide all
necessary inputs and output details, database controls and procedures. For ensuring a successful
implementation the system analysts should rather cater to each and every step must very carefully to
prepare a detailed system design. Data Flow Diagram (DFD) provides a visual representation of the flow
of information (i.e. data) within a system. By drawing a Data Flow diagram, one can tell the information
provided and delivered to someone who takes part in system processes, the information needed in order to
complete the processes and the information needed to be stored and accessed. ERD diagrams are used
together with corresponding DFDs to display the contents of a data store. They help us to visualize how
data is connected in a general way, and are particularly useful for constructing a database to recognize
relationships.