ERD: -

ER diagrams are a visual tool which is helpful to represent the ER model. It was proposed by
Peter Chen in 1971 to create a uniform convention which can be used for relational database and
network.

An Entity–relationship model (ER model) describes the structure of a database with the help of
a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model is a
design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.

What is an Entity Relationship Diagram (ER Diagram)?

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute
of a table in database, so by showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database. Lets have a look at a simple ER diagram to
understand this

A simple ER Diagram:

In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.

Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these terms
in detail in the next section(Components of a ER Diagram) of this guide so don’t worry too much
about these terms now, just go through them once.

Rectangle: Represents Entity sets.

Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set
Components of a ER Diagram

As shown in the above diagram, an ER diagram has three main components:

1. Entity
2. Attribute
3. Relationship

1. Entity

An entity is an object or component of data. An entity is represented as rectangle in an ER

diagram.
For example: In the following ER diagram we have two entities Student and College and these
two entities have many to one relationship as many students study in a single college. We will
read more about relationships later, for now focus on entities.

Weak Entity:
An entity that cannot be uniquely identified by its own attributes and relies on the relationship
with other entity is called weak entity. The weak entity is represented by a double rectangle. For
example – a bank account cannot be uniquely identified without knowing the bank to which the
account belongs, so bank account is a weak entity.
2. Attribute

An attribute describes the property of an entity. An attribute is represented as Oval in an ER

diagram. There are four types of attributes:

1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute

1. Key attribute:

A key attribute can uniquely identify an entity from an entity set. For example, student roll
number can uniquely identify a student from a set of students. Key attribute is represented by
oval same as other attributes however the text of key attribute is underlined.

2. Composite attribute:

An attribute that is a combination of other attributes is known as composite attribute. For

example, In student entity, the student address is a composite attribute as an address is composed
of other attributes such as pin code, state, country.

3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented
with double ovals in an ER Diagram. For example – A person can have more than one phone
numbers so the phone number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is
represented by dashed oval in an ER Diagram. For example – Person age is a derived attribute
as it changes over time and can be derived from another attribute (Date of birth).
E-R diagram with multivalued and derived attributes:

3. Relationship

A relationship is represented by diamond shape in ER diagram, it shows the relationship among

entities. There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it is
called one to one relationship. For example, a person has only one passport and a passport is
given to one person.

2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another entity
then it is called one to many relationship. For example – a customer can place many orders but a
order cannot be placed by many customers.

3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another entity
then it is called many to one relationship. For example – many students can study in a single
college but a student cannot study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of another
entity then it is called many to many relationship. For example, a can be assigned to many
projects and a project can be assigned to many students.

PPT:

Strong Entity Set Weak Entity Set

Strong entity set always has a primary It does not have enough attributes to build a
key. primary key.

It is represented by a rectangle symbol. It is represented by a double rectangle symbol.

It contains a Primary key represented by It contains a Partial Key which is represented

the underline symbol. by a dashed underline symbol.

The member of a strong entity set is The member of a weak entity set called as a
called as dominant entity set. subordinate entity set.

Primary Key is one of its attributes In a weak entity set, it is a combination of

which helps to identify its member. primary key and partial key of the strong entity
set.

In the ER diagram the relationship The relationship between one strong and a
between two strong entity set shown by weak entity set shown by using the double
using a diamond symbol. diamond symbol.
 The connecting line of the strong entity The line connecting the weak entity set for
set with the relationship is single. identifying relationship is double.

Attributes:

Types of Attributes Description

Simple attribute Simple attributes can't be divided any further.

For example, a student's contact number. It is
also called an atomic value.

Composite attribute It is possible to break down composite

attribute. For example, a student's full name
may be further divided into first name, second
name, and last name.

Derived attribute This type of attribute does not include in the

physical database. However, their values are
derived from other attributes present in the
database. For example, age should not be
stored directly. Instead, it should be derived
from the DOB of that employee.

Multivalued attribute Multivalued attributes can have more than one

values. For example, a student can have more
than one mobile number, email address, etc.

Steps to Create an ERD

Following are the steps to create an ERD.

Let's study them with an example:

In a university, a Student enrolls in Courses. A student must be assigned to at least one or more
Courses. Each course is taught by a single Professor. To maintain instruction quality, a Professor
can deliver only one course
Step 1) Entity Identification

We have three entities

 Student
 Course
 Professor

Step 2) Relationship Identification

We have the following two relationships

 The student is assigned a course

 Professor delivers a course

Step 3) Cardinality Identification

For them problem statement we know that,

 A student can be assigned multiple courses

 A Professor can deliver only one course
Step 4) Identify Attributes

You need to study the files, forms, reports, data currently maintained by the organization to
identify attributes. You can also conduct interviews with various stakeholders to identify entities.
Initially, it's important to identify the attributes without mapping them to a particular entity.

Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an
attribute is to be paired with exactly one entity. If you think an attribute should belong to more
than one entity, use a modifier to make it unique.

Once the mapping is done, identify the primary Keys. If a unique key is not readily available,
create one.

Entity Primary Key Attribute

Student Student_ID StudentName

Professor Employee_ID ProfessorName

Course Course_ID CourseName

Step 5) Create the ERD

PPT: Any object, for example, entities, attributes of an entity, relationship sets, and attributes of
relationship sets, can be represented with the help of an ER diagram.

Entity

Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.

Attributes

Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).
If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship

Relationships are represented by diamond-shaped box. Name of the relationship is written

inside the diamond-box. All the entities (rectangles) participating in a relationship, are
connected to it by a line.
Binary Relationship and Cardinality
A relationship where two entities are participating is called a binary relationship. Cardinality
is the number of instance of an entity from a relation that can be associated with the relation.
 One-to-one − When only one instance of an entity is associated with the relationship, it
is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.
  One-to-many − When more than one instance of an entity is associated with a
relationship, it is marked as '1:N'. The following image reflects that only one instance of
entity on the left and more than one instance of an entity on the right can be associated
with the relationship. It depicts one-to-many relationship.

 Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

 Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with the
relationship. It depicts many-to-many relationship.

he ER Model has the power of expressing database entities in a conceptual hierarchical manner.
As the hierarchy goes up, it generalizes the view of entities, and as we go deep in the hierarchy,
it gives us the detail of every entity included.
Going up in this structure is called generalization, where entities are clubbed together to
represent a more generalized view. For example, a particular student named Mira can be
generalized along with all the students. The entity shall be a student, and further, the student is a
person. The reverse is called specialization where a person is a student, and that student is
Mira.

Generalization

As mentioned above, the process of generalizing entities, where the generalized entities contain
the properties of all the generalized entities, is called generalization. In generalization, a number
of entities are brought together into one generalized entity based on their similar characteristics.
For example, pigeon, house sparrow, crow and dove can all be generalized as Birds.

Specialization

Specialization is the opposite of generalization. In specialization, a group of entities is divided

into sub-groups based on their characteristics. Take a group ‘Person’ for example. A person has
name, date of birth, gender, etc. These properties are common in all persons, human beings. But
in a company, persons can be identified as employee, employer, customer, or vendor, based on
what role they play in the company.

Similarly, in a school database, persons can be specialized as teacher, student, or a staff, based
on what role they play in school as entities.

Inheritance

We use all the above features of ER-Model in order to create classes of objects in object-
oriented programming. The details of entities are generally hidden from the user; this process
known as abstraction.
Inheritance is an important feature of Generalization and Specialization. It allows lower-level
entities to inherit the attributes of higher-level entities.

For example, the attributes of a Person class such as name, age, and gender can be inherited by
lower-level entities such as Student or Teacher.
 Example No.1

A manufacturing company produces products. The following product information is stored:

product name, product ID and quantity on hand. These products are made up of many
components. Each component can be supplied by one or more suppliers. The following
component information is kept: component ID, name, description, suppliers who supply them,
and products in which they are used

Example No.2

Create an ERD for a car dealership. The dealership sells both new and used cars, and it operates
a service facility (see Figure B.2). Base your design on the following business rules:

 A salesperson may sell many cars, but each car is sold by only one salesperson.
 A customer may buy many cars, but each car is bought by only one customer.
 A salesperson writes a single invoice for each car he or she sells.
 A customer gets an invoice for each car he or she buys.
 A customer may come in just to have his or her car serviced; that is, a customer need not buy a
car to be classified as a customer.
 When a customer takes one or more cars in for repair or service, one service ticket is written for
each car.
 The car dealership maintains a service history for each of the cars serviced. The service records
are referenced by the car’s serial number.
 A car brought in for service can be worked on by many mechanics, and each mechanic may work
on many cars.
 A car that is serviced may or may not need parts (e.g., adjusting a carburetor or cleaning a fuel
injector nozzle does not require providing new parts).

Decision Tree and Decision Table: -

A decision tree can have one branch with more conditions that need to be evaluated
than other branches on the tree. A decision table lists causes (business rule
condition), which are represented through the use of matrix where each column
represents a unique combination.
Decision table is a brief visual representation for specifying which actions to perform
depending on given conditions. The information represented in decision tables can also
be represented as decision trees or in a programming language using if-then-else and
switch-case statements.
A decision table is a good way to settle with different combination inputs with their
corresponding outputs and also called cause-effect table. Reason to call cause-effect
table is a related logical diagramming technique called cause-effect graphing that is
basically used to obtain the decision table.
Importance of Decision Table:
1. Decision tables are very much helpful in test design technique.
2. It helps testers to search the effects of combinations of different inputs and other
software states that must correctly implement business rules.
 3. It provides a regular way of stating complex business rules, that is helpful for
developers as well as for testers.
4. It assists in development process with developer to do a better job. Testing with all
combination might be impractical.
5. A decision table is basically an outstanding technique used in both testing and
requirements management.
6. It is a structured exercise to prepare requirements when dealing with complex
business rules.
7. It is also used in model complicated logic.
Decision Table in test designing:
Blank Decision Table
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1
Condition 2
Condition 3
Condition 4
Decision Table: Combinations
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N
Advantage of Decision Table:
1. Any complex business flow can be easily converted into the test scenarios & test
cases using this technique.
2. Decision tables work iteratively that means the table created at the first iteration is
used as input table for next tables. The iteration is done only if the initial table is
not satisfactory.
3. Simple to understand and everyone can use this method design the test scenarios
& test cases.
4. It provide complete coverage of test cases which help to reduce the rework on
writing test scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition
values. This is known as its completeness property.

Analysts use various tools to understand and describe the information system. One of the ways
is using structured analysis.

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development.
They are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudo code

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a

graphical form.
  It shows the flow of data between various functions of system and specifies how the
current system is implemented.
 It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.
 It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.
Basic Elements of DFD
DFD is easy to understand and quite effective when the required design is not clear and the user
wants a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution.
The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points
that differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows It is implementation independent. It

which functions are performed. focuses only on the flow of data between
processes.
It provides low level details of It explains events of systems and data
hardware, software, files, and people. required by each event.

It depicts how the current system It shows how business operates; not how
operates and how a system will be the system can be implemented.
implemented.

Context Diagram
A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then goes
onto giving more details of the processes with the top-down approach.
The context diagram of mess management is shown below.

OR

Data Flow Diagram (DFD) is a graphical representation of data flow in any system. It is
capable of illustrating incoming data flow, outgoing data flow and store data. Data flow
diagram describes anything about how data flows through the system.
Sometimes people get confused between data flow diagram and flowchart. There is a
major difference between data flow diagram and flowchart. The flowchart illustrates flow
of control in program modules. Data flow diagrams illustrate flow of data in the system
at various levels. Data flow diagram does not have any control or branch elements.
Types of DFD :
DFD is of two types:

1. Logical DFD:
Logical data flow diagram mainly focuses on the system process. It illustrates how
data flows in the system. Logical DFD is used in various organizations for the
 smooth running of system. Like in a Banking software system, it is used to
describe how data is moved from one entity to another.
2. Physical DFD:
Physical data flow diagram shows how the data flow is actually implemented in the
system. Physical DFD is more specific and close to implementation.
Components of Data Flow Diagram:
Following are the components of the data flow diagram that are used to represent
source, destination, storage and flow of data.

 Entities:
Entities include source and destination of the data. Entities are represented by
rectangle with their corresponding names.
 Process:
The tasks performed on the data is known as process. Process is represented by
circle. Somewhere round edge rectangles are also used to represent process.
 Data Storage:
Data storage includes the database of the system. It is represented by rectangle
with both smaller sides missing or in other words within two parallel lines.
 Data Flow:
The movement of data in the system is known as data flow. It is represented with
the help of arrow. The tail of the arrow is source and the head of the arrow is
destination.
Importance of Data Flow Diagram:
Data flow diagram is a simple formalism to represent the flow of data in the system. It
allows a simple set of intuitive concepts and rules. It is an elegant technique that is
useful to represent the results of structured analysis of software problem as well as to
represent the flow of documents in an organization

Data Dictionary

A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard feature.
For example, refer the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60
 3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees

Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.
For example, refer the following decision tree −
Decision Tables

Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.
 It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be carried
out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.
The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -
 Give no discount - - X X

Structured English

Structure English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
construction and imperative sentences designed to perform operation for action.
 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.
For example, see the following sequence of actions −
if customer pays advance
then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if

Pseudocode

A pseudocode does not conform to any programming language and expresses logic in plain
English.
 It may specify the physical programming logic without actual coding during and after the
physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your
requirements −
 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of the
system.
 Use structured English if there are many loops and actions are complex.
  Use decision tables when there are a large number of conditions to check and logic is
complex.
 Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested.

Input Design

In an information system, input is the raw data that is processed to produce output. During the
input design, the developers must consider the input devices such as PC, MICR, OMR, etc.
Therefore, the quality of system input determines the quality of system output. Welldesigned
input forms and screens have following properties −
 It should serve specific purpose effectively such as storing, recording, and retrieving the
information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles
regarding −
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.

Objectives for Input Design

The objectives of input design are −
 To design data entry and input procedures
 To reduce input volume
 To design source documents for data capture or devise other data capture methods
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.
Data Input Methods
It is important to design appropriate data input methods to prevent errors while entering data.
These methods depend on whether the data is entered by customers in forms manually and later
entered by data entry operators, or data is directly entered by users on the PCs.
A system should prevent user from making mistakes by −

 Clear form design by leaving enough space for writing legibly.

 Clear instructions to fill form.
 Clear form design.
 Reducing key strokes.
 Immediate error feedback.

Output Design
The design of output is the most important task of any system. During output design, developers
identify the type of outputs needed, and consider the necessary output controls and prototype
report layouts.
Objectives of Output Design
The objectives of input design are −
 To develop output design that serves the intended purpose and eliminates the production
of unwanted output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.

Forms Design

Both forms and reports are the product of input and output design and are business document
consisting of specified data. The main difference is that forms provide fields for data input but
reports are purely used for reading. For example, order forms, employment and credit
application, etc.
 During form designing, the designers should know −
o who will use them
o where would they be delivered
o the purpose of the form or report
 During form design, automated design tools enhance the developer’s ability to prototype
forms and reports and present them to end users for evaluation.
Objectives of Good Form Design
A good form design is necessary to ensure the following −
 To keep the screen simple by giving proper sequence, information, and clear captions.
 To meet the intended purpose by using appropriate forms.
 To ensure the completion of form with accuracy.
 To keep the forms attractive by using icons, inverse video, or blinking cursors etc.
 To facilitate navigation.