What is a data flow diagram (DFD)?

A data flow diagram (DFD) is a visual representation of the information flow through a process or system. DFDs help you better understand process or system operations to discover potential problems, improve efficiency, and develop better processes. They range from simple overviews to complex, granular displays of a process or system.

The Benefits of Data Flow Diagrams

DFDs are visual representations that can help almost anyone grasp a system‘s or process’ logic and functions. 

Data Flow Diagram Symbols

Four common methods of notation are used in DFDs: Yourdon & De Marco, Gene & Sarson, SSADM, and Unified.

1. External Entity

External entities — which are also known as terminators, sources, sinks, or actors — are outside systems that send or receive data to and from the diagrammed system.

2. Process

Process is a procedure that manipulates the data and its flow by taking incoming data, changing it, and producing an output. 

3. Data Store

Data stores hold information for later use, like a file of documents that’s waiting to be processed.

4. Data Flow

Data flow is the path the system’s information takes from external entities through processes and data stores..

DFD Levels

Level 0: Context Diagram

This DFD level focuses on high-level system processes or functions and the data sources that flow to or from them. Level 0 diagrams are designed to be simple, straightforward overviews of a process or system.

This Level 0 DFD provides a contextual map of a securities trading platform.

Data flows in one direction from the customer service assistant and the broker to the platform. It also flows in two directions from customers to the platform and back again.

Level 1: Process Decomposition

While level 1 DFDs are still broad overviews of a system or process, they’re also more detailed — they break down the system’s single process node into subprocesses.

What is ER Diagram

ER Diagram stands for Entity Relationship Diagram, also known as ERD is a diagram that displays the relationship of entity sets stored in a database. ER diagrams are created based on three basic concepts: entities, attributes and relationships.

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram

• Helps you to define terms related to entity relationship modeling
• Provide a preview of how all your tables should connect, what fields are going to be on each table
• Helps to describe entities, attributes, relationships
• ER diagrams are translatable into relational tables which allows you to build databases quickly
• ER diagrams can be used by database designers as a blueprint for implementing data in specific software applications

Components of the ER Diagram

This model is based on three basic concepts:

• Entities
• Attributes
• Relationships

ER Diagram Examples

For example, in a University database, we might have entities for Students, Courses, and Lecturers. Students entity can have attributes like Rollno, Name, and DeptID. They might have relationships with Courses and Lecturers.

WHAT IS ENTITY?

A real-world thing either living or non-living that is easily recognizable and nonrecognizable. It is anything in the enterprise that is to be represented in our database. It may be a physical thing or simply a fact about the enterprise or an event that happens in the real world.

An entity can be place, person, object, event or a concept, which stores data in the database. The characteristics of entities are must have an attribute, and a unique key. Every entity is made up of some ‘attributes’ which represent that entity.

Examples of entities:

• Person: Employee, Student, Patient
• Place: Store, Building
• Object: Machine, product, and Car
• Event: Sale, Registration, Renewal
• Concept: Account, Course

Cardinality

Defines the numerical attributes of the relationship between two entities or entity sets.

Different types of cardinal relationships are:

• One-to-One Relationships
• One-to-Many Relationships
• May to One Relationships
• Many-to-Many Relationships

1.One-to-one:

One entity from entity set X can be associated with at most one entity of entity set Y and vice versa.

Example: One student can register for numerous courses. However, all those courses have a single line back to that one student.

2.One-to-many:

One entity from entity set X can be associated with multiple entities of entity set Y, but an entity from entity set Y can be associated with at least one entity.

For example, one class is consisting of multiple students.

3. Many to Many:

One entity from X can be associated with more than one entity from Y and vice versa.

For example, Students as a group are associated with multiple faculty members, and faculty members can be associated with multiple students.

How to Create an Entity Relationship Diagram (ERD)

Following are the steps to create an ER Diagram:

UML Use Case Diagram

Use Case Diagram captures the system’s functionality and requirements by using actors and use cases. Use Cases model the services, tasks, function that a system needs to perform. Use cases represent high-level functionalities and how a user will handle the system. 

Use-case diagram notations

Following are the common notations used in a use case diagram:

Use-case:

Use cases are used to represent high-level functionalities and how the user will handle the system. A use case represents a distinct functionality of a system, a component, a package, or a class. It is denoted by an oval shape with the name of a use case written inside the oval shape. The notation of a use case in UML is given below:

Actor:

It is used inside use case diagrams. The actor is an entity that interacts with the system. A user is the best example of an actor. An actor is an entity that initiates the use case from outside the scope of a use case. It can be any element that can trigger an interaction with the use case. One actor can be associated with multiple use cases in the system.

How to draw a use-case diagram?

To draw a use case diagram in UML first one need to analyse the entire system carefully. You have to find out every single function that is provided by the system. After all the functionalities of a system are found out, then these functionalities are converted into various use cases which will be used in the use case diagram.

A use case is nothing but a core functionality of any working system. After organizing the use cases, we have to enlist the various actors or things that are going to interact with the system. These actors are responsible for invoking the functionality of a system. Actors can be a person or a thing. It can also be a private entity of a system. These actors must be relevant to the functionality or a system they are interacting with.

After the actors and use cases are enlisted, then you have to explore the relationship of a particular actor with the use case or a system. One must identify the total number of ways an actor could interact with the system. A single actor can interact with multiple use cases at the same time, or it can interact with numerous use cases simultaneously.

Following use case diagram represents the working of the student management system:

In the above use case diagram, there are two actors named student and a teacher. There are a total of five use cases that represent the specific functionality of a student management system. Each actor interacts with a particular use case. A student actor can check attendance, timetable as well as test marks on the application or a system. This actor can perform only these interactions with the system even though other use cases are remaining in the system.

It is not necessary that each actor should interact with all the use cases, but it can happen.

The second actor named teacher can interact with all the functionalities or use cases of the system. This actor can also update the attendance of a student and marks of the student. These interactions of both student and a teacher actor together sums up the entire student management application.

Published by Active Learning, Dec 2023