26 System Design (DFD & ER Diagrams)

Ms.Vinodini Kapoor

epgp books

 

 

1.    Learning Outcome:

  • 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:

  • Conceptual design gives a holistic structure and overall performance specification while the detailed design gives operational and construction specification.
  • 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.
  • 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.
  • Conceptual design provides the structure while the detailed design makes the structure to be operational.
  1. 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.

 

 

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.

 

 

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 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.

 

 

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.

 

 

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.

 

 

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

 

  • 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.
  • Multivalued Attribute –An attribute that can possess more than one value is called a multivalued 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.
  • Derived Attribute – This is the case of an attribute based on another attribute. This is found rarely in ER diagrams.
  • 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.
  • 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

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.

 

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.

 

 

5.3 Building effective ER Diagrams

 

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

  • To identify all the relevant entities in a given system and determine the relationships among these entities.
  • An entity should have the occurrence only once in a particular diagram.
  • It is essential to provide a precise and appropriate name for each entity, attribute, and relationship in the diagram.
  • 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.
  • It is essential to discard vague, redundant or unnecessary relationships between entities.
  • It is important to note that one relationship cannot be connected to another.
  • It is advisable to use colors effectively to highlight key areas in diagrams.

 

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.

you can view video on System Design (DFD & ER Diagrams)

Web Resources