DATABASE MANAGEMENT SYSTEM

UNIT-2
SYLLABUS:

Relational database model - logical view of data-keys -Integrity rules - relational set operators -
data dictionary - Codd's rules. Entity relationship model - ER diagram

Relational Model in DBMS

The Relational Model organizes data using tables (relations) consisting of rows and columns.
 The relational model represents how data is stored and managed in Relational Databases
where data is organized into tables, each known as a relation.
 Each row of a table represents an entity or record and each column represents a particular
attribute of that entity.
 The relational model transforms conceptual designs from ER diagrams into
implementable structures. These structures are used in relational database systems like
Oracle SQL and MySQL.
Example: Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS,
PHONE and AGE shown in the table.

Key Terms in the Relational Model

1. Attribute: Attributes are the properties that define an entity. For example, ROLL_NO,
NAME, ADDRESS etc.
2. Relation Schema: A relation schema defines the structure of the relation and represents
the name of the relation with its attributes. For example, STUDENT (ROLL_NO, NAME,
ADDRESS, PHONE and AGE) is the relation schema for STUDENT. If a schema has
more than 1 relation it is called Relational Schema.
3. Tuple: A Tuple represents a row in a relation. Each tuple contains a set of attribute values
that describe a particular entity. For example, (1, RAM, DELHI, 9455123451, 18) is a
tuple in the STUDENT table.
4. Relation Instance: The set of tuples of a relation at a particular instance of time is called
a relation instance. It can change whenever there is an insertion, deletion or update in the
database.
5. Degree: The number of attributes in the relation is known as the degree of the relation.
For example, The STUDENT relation has a degree of 5, as it has 5 attributes.
6. Cardinality: The number of tuples in a relation is known as cardinality. For example,
The STUDENT relation defined above has cardinality 4.
7. NULL Values: The value which is not known or unavailable is called a NULL value. It is
represented by NULL. For example, PHONE of STUDENT having ROLL_NO 4 is
NULL.
Types of Keys in the Relational Model
1. Primary Key: A Primary Key uniquely identifies each tuple in a relation. It must contain
unique values and cannot have NULL values.
2. Candidate Key: A Candidate Key is a set of attributes that can uniquely identify a tuple
in a relation.
3. Super Key: A Super Key is a set of attributes that can uniquely identify a tuple.
4. Foreign Key: A Foreign Key is an attribute in one relation that refers to the primary key
of another relation.
5. Composite Key: A Composite Key is formed by combining two or more attributes to
uniquely identify a tuple.
Relational Model Notation
 Relation schema R of degree n is denoted by by R(A1, A2, ...,An).
 Uppercase letters Q, R, S denote relation names.
 Lowercase letters q, r, s denote relation states.
 Letters t, u, v denote tuples.
 In general, the name of a relation schema such as STUDENT also indicates the current set
of tuples in that relation.
 An attribute A can be qualified with the relation name R to which it belongs by using the
dot notation R.A for example, STUDENT.Name or STUDENT.Age.
 An n-tuple t in a relation r(R) is represented as t = <v1, v2,..., vn> where vi is the value
corresponding to the attribute Ai. The value vi for attribute Ai in tuple t can be accessed
using t[Ai] or t.Ai.
Characteristics of the Relational Model
 Data Representation: Data is organized in tables (relations), with rows (tuples)
representing records and columns (attributes) representing data fields.
 Atomic Values: Each attribute in a table contains atomic values, meaning no multi-
valued or nested data is allowed in a single cell.
 Unique Keys: Every table has a primary key to uniquely identify each record, ensuring
no duplicate rows.
 Attribute Domain: Each attribute has a defined domain, specifying the valid data types
and constraints for the values it can hold.
 Data Independence: The model ensures logical and physical data independence,
allowing changes in the database schema without affecting the application layer.
 Relational Operations: Supports operations like selection, projection, join, union and
intersection, enabling powerful data retrieval manipulation.
 Data Consistency: Ensures data consistency through constraints, reducing redundancy
and anomalies.
 Set-Based Representation: Tables in the relational model are treated as sets and
operations follow mathematical set theory principles.
Constraints in Relational Model
While designing the Relational Model, we define some conditions which must hold for data
present in the database are called Constraints. These constraints are checked before
performing any operation (insertion, deletion and updation) in the database. If there is a
violation of any of the constraints, the operation will fail.
1. Domain Constraints
Domain Constraints ensure that the value of each attribute A in a tuple must be an atomic
value derived from its specified domain, dom(A). Domains are defined by the data types
associated with the attributes. Common data types include:
 Numeric types: Includes integers (short, regular and long) for whole numbers and real
numbers (float, double-precision) for decimal values, allowing precise calculations.
 Character types: Consists of fixed-length (CHAR) and variable-length (VARCHAR,
TEXT) strings for storing text data of various sizes.
 Boolean values: Stores true or false values, often used for flags or conditional checks in
databases.
 Specialized types: Includes types for date (DATE), time (TIME), timestamp
(TIMESTAMP) and money (MONEY), used for precise handling of time-related and
financial data.
2. Key Integrity
Every relation in the database should have at least one set of attributes that defines a tuple
uniquely. Those set of attributes is called keys. e.g.; ROLL_NO in STUDENT is key. No two
students can have the same roll number. So a key has two properties:
 It should be unique for all tuples.
 It can’t have NULL values.
3. Referential Integrity Constraints
When one attribute of a relation can only take values from another attribute of the same
relation or any other relation, it is called referential integrity. Let us suppose we have 2
relations

Table: STUDENT
ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE

1 RAM DELHI 9455123451 18 CS

2 RAMESH GURGAON 9652431543 18 CS

3 SUJIT ROHTAK 9156253131 20 ECE

4 SURESH DELHI 18 IT
 Table: BRANCH
BRANCH_CODE BRANCH_NAME

CS COMPUTER SCIENCE

IT INFORMATION TECHNOLOGY

ELECTRONICS AND
ECE
COMMUNICATION ENGINEERING

CV CIVIL ENGINEERING

Explanation: BRANCH_CODE of STUDENT can only take the values which are present in
BRANCH_CODE of BRANCH which is called referential integrity constraint. The relation
which is referencing another relation is called REFERENCING RELATION (STUDENT in
this case) and the relation to which other relations refer is called REFERENCED RELATION
(BRANCH in this case).
Anomalies in the Relational Model
An anomaly is an irregularity or something which deviates from the expected or normal state.
When designing databases, we identify three types of anomalies: Insert, Update, and Delete.
 Insertion Anomaly in Referencing Relation: We can’t insert a row in REFERENCING
RELATION if referencing attribute’s value is not present in the referenced attribute
value. e.g.; Insertion of a student with BRANCH_CODE ‘ME’ in STUDENT relation will
result in an error because ‘ME’ is not present in BRANCH_CODE of BRANCH.
 Deletion/ Updation Anomaly in Referenced Relation:

We can’t delete or update a row from REFERENCED RELATION if the value of

REFERENCED ATTRIBUTE is used in the value of REFERENCING ATTRIBUTE. For
example, If we try to delete a tuple from BRANCH having BRANCH_CODE ‘CS’, it will
result in an error because ‘CS’ is referenced by BRANCH_CODE of STUDENT, but if we
try to delete the row from BRANCH with BRANCH_CODE CV, it will be deleted as the
value is not been used by referencing relation.

 Set Operators in SQL

Set operations form the foundation of SQL and enable us to combine, compare, and filter data
from multiple sources. These operations are indispensable for tasks ranging from data
integration and cleansing to advanced analytics and reporting.

Set operations in SQL are techniques for combining or comparing the results of two or more
SELECT statements. They act like mathematical set operations, letting us find the union,
intersection, or difference between the rows returned by our queries. This makes them
indispensable when analyzing data from multiple sources or perspectives.
 Here's a quick overview of the core set operations:

 UNION: Merges all unique rows from two or more SELECT statements, eliminating
duplicates.
 UNION ALL: Merges all rows from two or more SELECT statements, keeping duplicates.
 INTERSECT: Returns only the rows that appear in both SELECT statements.
 EXCEPT: Returns rows from the first SELECT statement that don't appear in the second.

Understanding Set Operators

Set operators are specialized commands or symbols used to perform operations on the result
sets of multiple SELECT queries. They enable us to perform tasks like finding the union (all
rows), intersection (shared rows), and difference (unique rows) between different datasets.

Set operators are essential tools for data manipulation and analysis within SQL. They provide a
powerful means of querying and processing data from relational databases.

Comparison with relational algebra operations

Relational algebra is a theoretical framework that provides a foundation for understanding

database queries. It offers abstract operations like projection, selection, and join, rooted in
mathematical principles and independent of specific database systems. Think of it as the
"behind-the-scenes" logic that powers our database interactions.

Set operators in SQL offer a practical implementation of these concepts within a database
environment. They enable us to perform set operations like union, intersection, and difference
directly on the result sets of SQL queries.

While relational algebra provides a formal foundation for database operations, set operators in
SQL offer a standardized, user-friendly interface for data manipulation tasks.

Understanding the relationship between set operators and relational algebra operations provides
insights into the theoretical underpinnings of SQL. It enables users to leverage these concepts
effectively in database querying and analysis tasks.

Types of Set Operators in SQL

There are three primary set operators in SQL:

 UNION
 INTERSECT
 EXCEPT (or MINUS in some dialects)
These operators mathematically correspond to the concepts of union, intersection, and set
difference.
 The UNION operator

The UNION operator combines the results of two or more SELECT queries into a single result
set, removing duplicate rows by default.

For example, suppose we have two tables, employees and contractors, each with similar
columns such as contractors, department, and salary. For learning purposes, let’s consider these
two dummy tables:

name department salary

Alice Marketing 65000

Bob Sales 70000

Carol Engineering 80000

John HR 55000

Employees

name department salary

David Marketing 60000

Eva Sales 68000

Carol Engineering 75000

Contractors

We can combine the results from both tables using the following command:

-- Using INTERSECT to find common employees

SELECT name, department FROM employees

INTERSECT
SELECT name, department FROM contractors;
This query selects the name, department, and salary columns from both
the employees and contractors tables and combines them into a single result set. The UNION
operator automatically removes duplicate rows from the final result set.

name department salary

Alice Marketing 65000

Bob Sales 70000

Carol Engineering 80000

John HR 55000

David Marketing 60000

Eva Sales 68000

Notice that Carol, who appears in both tables, is only listed once in the result. If we wanted to
keep both instances of Carol (with her different salaries), we would use UNION ALL.

It's important to remember that the UNION operator does not remove NULL values. If a
column contains NULL values in one result set and non-NULL values in the corresponding
column of another result set, the NULL values will be retained in the final result set produced
by the UNION operator.

If we want to include NULL values in the result set and prevent their removal by the UNION
operator, we can use the UNION ALL operator instead. This operator combines the results of
multiple SELECT queries, including all rows from each result set, regardless of whether they
are duplicates or contain NULL values.

The INTERSECT operator

The INTERSECT operator returns only the rows that appear in both result sets. Think of it as
finding the people who belong to both groups.

Let’s use INTERSECT to query our tables above. For the sake of the example, let’s just query
the name and department columns:

-- Using INTERSECT to find common employees

SELECT name, department FROM employees

INTERSECT
SELECT name, department FROM contractors;
This query selects the name and department columns from both the employees and contractors
tables and returns only the rows that exist in both tables based on all selected columns.

name department

Carol Engineering

The INTERSECT operator handles NULL values based on standard comparison rules,
considering NULL values equal when comparing corresponding columns. It also results in an
empty set when dealing with empty result sets.

In other words, if a NULL value is present in one result set and the corresponding column in
the other result set contains a non-NULL value, the rows are not considered equal – they will
not be included in the intersection result.

Additionally, If one of the result sets provided to the INTERSECT operator is empty (i.e., it
contains no rows), the overall result of the INTERSECT operation will also be empty since
there are no common rows between an empty set and any other set.

The EXCEPT (MINUS) operator

The EXCEPT operator retrieves the rows present in the first result set but not in the second.

For example, let’s say we execute the following query:

-- Using EXCEPT to find employees who are not contractors

SELECT name, department, salary FROM employees

EXCEPT
SELECT name, department, salary FROM contractors;
The name, department, and salary columns are selected from the employees table and return
only the rows that do not exist in the contractors table.

name department salary

Alice Marketing 65000

Bob Sales 70000

John HR 55000

The EXCEPT operator also follows standard comparison rules for handling NULL values. Its
behavior with empty result sets results in an empty set if the first result set is empty or includes
all rows from the first result set if the second result set is empty.
Set Operators: Performance and Optimization

The impact of set operators on query performance in SQL can vary depending on factors such
as the size of the datasets involved, the complexity of the queries, and the database
management system (DBMS) used.

Let's break down the key factors and strategies for optimization.

Data volume and query complexity

When working with large amounts of data, set operators can significantly impact query
performance because the size of the result sets that need to be combined, intersected, or
compared increases the processing time required to perform that operation.

Complex queries containing multiple subqueries, joins, or set operators may result in additional
processing overhead and impact query performance. Chained operations or nested set
operations could further exacerbate performance consequences.

Indexing and optimization techniques

Proper indexing of the columns involved in set operations can significantly improve query
performance. Indexes help the database engine quickly locate and retrieve the relevant rows,
reducing the need for full-table scans and improving query execution times.

To enhance the performance of queries involving set operators, database administrators, and
developers can utilize optimization techniques like query rewriting, query plan analysis, and
database schema optimization. Techniques like query caching and materialized views can also
be used to precompute and store the results of complex queries, reducing the computational
overhead of set operations.

Database engine and hardware resources

The performance of set operations may vary depending on the underlying database engine and
its optimization capabilities. Different DBMSs may employ different optimization strategies
and algorithms for processing set operations, leading to variations in performance.

The availability of hardware resources such as CPU, memory, and disk I/O also influences the
performance of queries involving set operators. Adequate hardware resources can help mitigate
performance bottlenecks and ensure efficient query execution.

Codd's Rule for Relational DBMS

E.F Codd was a Computer Scientist who invented the Relational model for Database
management. Based on relational model, the Relational database was created. Codd proposed
13 rules popularly known as Codd's 12 rules to test DBMS's concept against his relational
model. Codd's rule actualy define what quality a DBMS requires in order to become a
Relational Database Management System(RDBMS). Till now, there is hardly any commercial
product that follows all the 13 Codd's rules. Even Oracle follows only eight and half(8.5) out
of 13. The Codd's 12 rules are as follows.
 Rule zero

This rule states that for a system to qualify as an RDBMS, it must be able to manage database
entirely through the relational capabilities.

Rule 1: Information rule

All information(including metadata) is to be represented as stored data in cells of tables. The

rows and columns have to be strictly unordered.

Rule 2: Guaranted Access

Each unique piece of data(atomic value) should be accesible by : Table Name + Primary
Key(Row) + Attribute(column).

NOTE: Ability to directly access via POINTER is a violation of this rule.

Rule 3: Systematic treatment of NULL

Null has several meanings, it can mean missing data, not applicable or no value. It should be
handled consistently. Also, Primary key must not be null, ever. Expression on NULL must give
null.

Rule 4: Active Online Catalog

Database dictionary(catalog) is the structure description of the complete Database and it must
be stored online. The Catalog must be governed by same rules as rest of the database. The same
query language should be used on catalog as used to query database.

Rule 5: Powerful and Well-Structured Language

One well structured language must be there to provide all manners of access to the data stored
in the database. Example: SQL, etc. If the database allows access to the data without the use of
this language, then that is a violation.

Rule 6: View Updation Rule

All the view that are theoretically updatable should be updatable by the system as well.

Rule 7: Relational Level Operation

There must be Insert, Delete, Update operations at each level of relations. Set operation like
Union, Intersection and minus should also be supported.
 Rule 8: Physical Data Independence

The physical storage of data should not matter to the system. If say, some file supporting table
is renamed or moved from one disk to another, it should not effect the application.

Rule 9: Logical Data Independence

If there is change in the logical structure(table structures) of the database the user view of data
should not change. Say, if a table is split into two tables, a new view should give result as the
join of the two tables. This rule is most difficult to satisfy.

Rule 10: Integrity Independence

The database should be able to enforce its own integrity rather than using other programs. Key
and Check constraints, trigger etc, should be stored in Data Dictionary. This also
make RDBMS independent of front-end.

Rule 11: Distribution Independence

A database should work properly regardless of its distribution across a network. Even if a
database is geographically distributed, with data stored in pieces, the end user should get an
impression that it is stored at the same place. This lays the foundation of distributed database.

Rule 12: Nonsubversion Rule

If low level access is allowed to a system it should not be able to subvert or bypass integrity
rules to change the data. This can be achieved by some sort of looking or encryption.

Introduction of ER Model

The Entity-Relationship Model (ER Model) is a conceptual model for designing a databases.
This model represents the logical structure of a database, including entities, their attributes
and relationships between them.
 Entity: An objects that is stored as data such as Student, Course or Company.
 Attribute: Properties that describes an entity such as StudentID, CourseName,
or EmployeeEmail.
 Relationship: A connection between entities such as "a Student enrolls in a Course".
The graphical representation of this model is called an Entity-Relation Diagram (ERD).
ER Model in Database Design Process
We typically follow the below steps for designing a database for an application.
 Gather the requirements (functional and data) by asking questions to the database users.
 Create a logical or conceptual design of the database. This is where ER model plays a
role. It is the most used graphical representation of the conceptual design of a database.
 After this, focus on Physical Database Design (like indexing) and external design (like
views)
Why Use ER Diagrams In DBMS?
 ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).
 These diagrams serve the purpose of real-world modeling of objects which makes them
intently useful.
 Unlike technical schemas, ER diagrams require no technical knowledge of the underlying
DBMS used.
 They visually model data and its relationships, making complex systems easier to
understand.
Symbols Used in ER Model
ER Model is used to model the logical view of the system from a data perspective which
consists of these symbols:
 Rectangles: Rectangles represent entities in the ER Model.
 Ellipses: Ellipses represent attributes in the ER Model.
 Diamond: Diamonds represent relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double ellipses represent multi-valued Attributes, such as a student's
multiple phone numbers
 Double Rectangle: Represents weak entities, which depend on other entities for
identification.

What is an Entity?
An Entity represents a real-world object, concept or thing about which data is stored in a
database. It act as a building block of a database. Tables in relational database represent these
entities.
Example of entities:
 Real-World Objects: Person, Car, Employee etc.
 Concepts: Course, Event, Reservation etc.
 Things: Product, Document, Device etc.
The entity type defines the structure of an entity, while individual instances of that type
represent specific entities.
What is an Entity Set?
An entity refers to an individual object of an entity type, and the collection of all entities of a
particular type is called an entity set. For example, E1 is an entity that belongs to the entity
type "Student," and the group of all students forms the entity set.
In the ER diagram below, the entity type is represented as:

Entity Set
We can represent the entity sets in an ER Diagram but we can't represent individual entities
because an entity is like a row in a table, and an ER diagram shows the structure and
relationships of data, not specific data entries (like rows and columns). An ER diagram is a
visual representation of the data model, not the actual data itself.
Types of Entity
There are two main types of entities:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute that can uniquely identify each
instance of the entity. A Strong Entity does not depend on any other Entity in the Schema for
its identification. It has a primary key that ensures its uniqueness and is represented by a
rectangle in an ER diagram.
2. Weak Entity
A Weak Entity cannot be uniquely identified by its own attributes alone. It depends on a
strong entity to be identified. A weak entity is associated with an identifying entity (strong
entity), which helps in its identification. A weak entity are represented by a double rectangle.
The participation of weak entity types is always total. 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.
Example:
A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can't exist without the employee. So dependent will be a Weak
Entity Type and Employee will be identifying entity type for dependent, which means it is
Strong Entity Type.

Strong Entity and Weak Entity

Attributes in ER Model
Attributes are the properties that define the entity type. For example, for a Student entity
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 an underline.

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.
The Complete Entity Type Student with its Attributes can be represented as:

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example, ‘Enrolled
in’ is a relationship type that exists between entity type Student and Course. In ER diagram,
the relationship type is represented by a diamond and connecting the entities with lines.

Entity-Relationship Set

A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.

Relationship Set

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.

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

Binary Relationship

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 in ER Model
The maximum 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.

Using Sets, it can be represented as:

Set Representation of 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. 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.

Using sets, one-to-many cardinality can be represented as:

Set Representation of One-to-Many

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.
many to one cardinality
Using Sets, it can be represented as:

Set Representation of Many-to-One

In this case, each student is taking only 1 course but 1 course has been taken by many
students.
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.
many to many cardinality
In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3, and
S4. So it is many-to-many relationships.
Participation Constraint
Participation Constraint is applied to the entity participating in the relationship set.
1. Total Participation: Each entity in the entity set must participate in the relationship. If
each student must enroll in a course, the participation of students will be total. Total
participation is shown by a double line in the ER diagram.
2. Partial Participation: The entity in the entity set may or may NOT participate in the
relationship. If some courses are not enrolled by any of the students, the participation in the
course will be partial.

The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set having total
participation and Course Entity set having partial participation.

Total Participation and Partial Participation

Using Set, it can be represented as,

Set representation of Total Participation and Partial Participation

Every student in the Student Entity set participates in a relationship but there exists a course
C4 that is not taking part in the relationship.
How to Draw an ER Diagram
1. Identify Entities: The very first step is to identify all the Entities. Represent these entities
in a Rectangle and label them accordingly.
2. Identify Relationships: The next step is to identify the relationship between them and
represent them accordingly using the Diamond shape. Ensure that relationships are not
directly connected to each other.
3. Add Attributes: Attach attributes to the entities by using ovals. Each entity can have
multiple attributes (such as name, age, etc.), which are connected to the respective entity.
4. Define Primary Keys: Assign primary keys to each entity. These are unique identifiers
that help distinguish each instance of the entity. Represent them with underlined attributes.
5. Remove Redundancies: Review the diagram and eliminate unnecessary or repetitive
entities and relationships.
6. Review for Clarity: Review the diagram make sure it is clear and effectively conveys the
relationships between the entities.