OBJECT ORIENTED SOFTWARE ENGINEERING

ASSIGNMENT -1

NAME : AJAY S
CLASS : CSE III YEAR
REG NO : 910022104001
TOPIC : DATA FLOW DIAGRAM
ER DIAGRAM
NORMALISATION
 DATA FLOW DIAGRAM (DFD)
➢ Data flow diagrams are used to graphically represent the flow of data in a
business information system. DFD describes the processes that are
involved in a system to transfer data from the input to the file storage and
reports generation.

Types of Data Flow Diagrams (DFDs):

1. Logical Data Flow Diagram

➢ Logical data flow diagram mainly focuses on the system process. It
illustrates how data flows in the system. In the Logical Data Flow Diagram
(DFD), we focus on the high-level processes and data flow without delving
into the specific implementation details.

2.Physical Data Flow Diagram (DFD)

➢ A Physical Data Flow Diagram (Physical DFD) represents how data flows
within a system, including hardware, software, people, and processes
involved in data movement. It focuses on the actual implementation of the
system, detailing who processes the data and how it is stored, transmitted,
and processed.

Levels of Data Flow Diagram (DFD):

1.Level 0 (Context Diagram)

• Represents the system as a single process.

• Shows the interaction between the system and external entities.
• Provides a high-level overview without internal details.
 2. Level 1 DFD
• Breaks down the main process into multiple sub-processes.
• Introduces data stores and internal flows.
• Shows a more detailed structure of the system.

3. Level 2

• Further expands each sub-process from Level 1.

• Includes specific data movements and operations.
• Offers a comprehensive and detailed view of the system’s
workflow.

Example: Online Shopping System

Level 0 (Context Diagram)

• The system interacts with Customers and Bank Database.

• Customers can view account details, transfer funds, and pay bills.
• The system processes transactions and updates records in the bank
database.

Diagram:

ONLINE
PAYMENT
CUSTOMER SHOPPING
GATEWAY
SYSTEM

Level 1 DFD

•The system is divided into:

 • Book Product
• Add to cart
• Make payment

Diagram:

BROWSE ADD TO MAKE

CUSTOMER PRODUCT CART PAYMENT

Level 2 DFD
• The Book Borrowing module is further divided into:
• Credit card payment
• UPI payment
CREDIT CARD
PAYMENT

MAKE
PAYMENT
UPI
PAYMENT

Conclusion

DFDs help in understanding system workflows, reducing complexity, and

improving system design. They are widely used in software development,
business process modeling, and system documentation.
 ENTITY-RELATIONSHIP (E-R) DIAGRAM

An entity-relationship (e-r) diagram is a visual representation of data in a system

that outlines how different entities (objects or concepts) relate to one another. It
is commonly used in database design to organize data logically and structurally.

TYPES OF ENTITY

There are two types of entity:

1. STRONG ENTITY

A strong entity is a type of entity that has a key attribute. strong entity does not
depend on other entity in the schema. it has a primary key, that helps in identifying
it uniquely, and it is represented by a rectangle. these are called strong entity
types.

2. WEAK ENTITY

An entity type has a key attribute that uniquely identifies each entity in the entity
set. but some entity type exists for which key attributes can’t be defined.

• A weak entity type is represented by a Double Rectangle

• The relationship between the weak entity type and its identifying strong
entity type is called identifying relationship and it is represented by a
double diamond.
ATTRIBUTES

Attributes are the properties that define the entity type. For example, Roll_No,
Name, DOB, Age, Address, and Mobile_No are the attributes that define entity
type Student. In ER diagram, the attribute is represented by an oval.

Types of Attributes

1. Key Attribute

The attribute which uniquely identifies each entity in the entity set is called the
key attribute. For example, Roll_No will be unique for each student. In ER
diagram, the key attribute is represented by an oval with underlying lines.

2.Composite Attribute

An attribute composed of many other attributes is called a composite attribute.

For example, the Address attribute of the student Entity type consists of Street,
City, State, and Country. In ER diagram, the composite attribute is represented by
an oval comprising of ovals.
3.Multivalued Attribute

An attribute consisting of more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram, a
multivalued attribute is represented by a double oval

4. Derived Attribute

An attribute that can be derived from other attributes of the entity type is known
as a derived attribute. e.g.; Age (can be derived from DOB). In ER diagram, the
derived attribute is represented by a dashed oval.
DEGREE OF A RELATIONSHIP SET

The number of different entity sets participating in a relationship set is called

the degree of a relationship set.

1. Unary Relationship:
When there is only ONE entity set participating in a relation, the
relationship is called a unary relationship. For example, one person is
married to only one person.

2. Binary Relationship:
When there are TWO entities set participating in a relationship, the
relationship is called a binary relationship. For example, a Student is
enrolled in a Course.

3. Ternary Relationship:
When there are three entity sets participating in a relationship, the
relationship is called a ternary relationship.
4. N-ary Relationship:
When there are n entities set participating in a relationship, the
relationship is called an n-ary relationship.
CARDINALITY:

The number of times an entity of an entity set participates in a relationship set is

known as cardinality . Cardinality can be of different types:

1. One-to-One:
When each entity in each entity set can take part only once in the
relationship, the cardinality is one-to-one. Let us assume that a male can
marry one female and a female can marry one male. So the relationship
will be one-to-one.

2.One-to-Many:

In one-to-many mapping as well where each entity can be related to more than
one entity and the total number of tables that can be used in this is 2. Let us
assume that one surgeon department can accommodate many doctors. So the
Cardinality will be 1 to M. It means one department has many Doctors.
3.Many-to-One:

When entities in one entity set can take part only once in the relationship set and
entities in other entity sets can take part more than once in the relationship set,
cardinality is many to one. Let us assume that a student can take only one course
but one course can be taken by many students. So the cardinality will be n to 1. It
means that for one course there can be n students but for one student, there will
be only one course.
 4.Many-to-Many:

When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can
take more than one course and one course can be taken by many students.
So the relationship will be many to many.

CONCLUSION OF ENTITY-RELATIONSHIP (E-R) DIAGRAM

The Entity-Relationship (E-R) diagram is a powerful tool for designing and

visualizing database structures. It helps in understanding how different entities
interact, ensuring efficient data organization and retrieval. By clearly defining
entities, attributes, and relationships, an E-R diagram aids in minimizing
redundancy and improving data integrity.
 NORMALIZATION IN DBMS

Normalization is a process in database management systems (dbms) that

organizes data to reduce redundancy and improve data integrity. It involves
breaking down a database into smaller, related tables and defining relationships
between them.

Types of Normal Forms

❖ First Normal Form (1NF): This is the most basic level of normalization.
In 1NF, each table cell should contain only a single value, and each
column should have a unique name. The first normal form helps to
eliminate duplicate data and simplify queries

❖ Second Normal Form (2NF): 2NF eliminates redundant data by

requiring that each non-key attribute be dependent on the primary key.
This means that each column should be directly related to the primary
key, and not to other columns.
❖ Third Normal Form (3NF): 3NF builds on 2NF by requiring that all
non-key attributes are independent of each other. This means that each
column should be directly related to the primary key, and not to any other
columns in the same table.

❖ Boyce-Codd Normal Form (BCNF): BCNF is a stricter form of 3NF

that ensures that each determinant in a table is a candidate key. In other
words, BCNF ensures that each non-key attribute is dependent only on
the candidate key.
 ❖ Fourth Normal Form (4NF): 4NF is a further refinement of BCNF that
ensures that a table does not contain any multi-valued dependencies.
❖ Fifth Normal Form (5NF): 5NF is the highest level of normalization
and involves decomposing a table into smaller tables to remove data
redundancy and improve data integrity.

CONCLUSION:
Normalization improves database design by reducing redundancy and ensuring
consistency, making the system more scalable, efficient, and easier to
maintain. However, excessive normalization may lead to complex queries and
performance overhead, so a balance between normalization and denormalization
is often necessary.