Data Models in DBMS

A Data Model in Database Management System

(DBMS) is the concept of tools that are developed to
summarize the description of the database. Data
Models provide us with a transparent picture of data
which helps us in creating an actual database. It shows
us from the design of the data to its proper
implementation of data.
Types of Relational Models
1. Conceptual Data Model
2. Representational Data Model
3. Physical Data Model
It is basically classified into 3 types:-

1. Conceptual Data Model

The conceptual data model describes the database at a
very high level and is useful to understand the needs or
requirements of the database. It is this model, that is
used in the requirement-gathering process i.e. before
the Database Designers start making a particular
database. One such popular model is
the entity/relationship model (ER model). The E/R
model specializes in entities, relationships, and even
attributes that are used by database designers. In
terms of this concept, a discussion can be made even
with non-computer science(non-technical) users and
stakeholders, and their requirements can be
understood.
Entity-Relationship Model( ER Model): It is a high-level
data model which is used to define the data and the
relationships between them. It is basically a conceptual
design of any database which is easy to design the view
of data.
Components of ER Model:
1. Entity: An entity is referred to as a real-world
object. It can be a name, place, object, class, etc.
These are represented by a rectangle in an ER
Diagram.
2. Attributes: An attribute can be defined as the
description of the entity. These are represented by
Ellipse in an ER Diagram. It can be Age, Roll
Number, or Marks for a Student.
 3. Relationship: Relationships are used to define
relations among different entities. Diamonds and
Rhombus are used to show Relationships.
Characteristics of a conceptual data model
 Offers Organization-wide coverage of the business
concepts.
 This type of Data Models are designed and
developed for a business audience.
 The conceptual model is developed independently
of hardware specifications like data storage
capacity, location or software specifications like
DBMS vendor and technology. The focus is to
represent data as a user will see it in the “real
world.”
Conceptual data models known as Domain models
create a common vocabulary for all stakeholders by
establishing basic concepts and scope
2. Representational Data Model
This type of data model is used to represent only the
logical part of the database and does not represent the
physical structure of the database. The
representational data model allows us to focus
primarily, on the design part of the database. A popular
representational model is a Relational model. The
relational Model consists of Relational
Algebra and Relational Calculus. In the Relational
Model, we basically use tables to represent our data
and the relationships between them. It is a theoretical
concept whose practical implementation is done in
Physical Data Model.
The advantage of using a Representational data model
is to provide a foundation to form the base for the
Physical model
3. Physical Data Model
The physical Data Model is used to practically
implement Relational Data Model. Ultimately, all data
in a database is stored physically on a secondary
storage device such as discs and tapes. This is stored in
the form of files, records, and certain other data
structures. It has all the information on the format in
which the files are present and the structure of the
databases, the presence of external data structures,
and their relation to each other. Here, we basically save
tables in memory so they can be accessed efficiently. In
order to come up with a good physical model, we have
to work on the relational model in a better
way. Structured Query Language (SQL) is used to
practically implement Relational Algebra.
This Data Model describes HOW the system will be
implemented using a specific DBMS system. This model
is typically created by DBA and developers. The
purpose is actual implementation of the database.
Characteristics of a physical data model:
 The physical data model describes data need for a
single project or application though it maybe
integrated with other physical data models based
on project scope.
 Data Model contains relationships between tables
that which addresses cardinality and nullability of
the relationships.
 Developed for a specific version of a DBMS,
location, data storage or technology to be used in
the project.
 Columns should have exact datatypes, lengths
assigned and default values.
 Primary and Foreign keys, views, indexes, access
profiles, and authorizations, etc. are defined
Some Other Data Models
1. Hierarchical Model
The hierarchical Model is one of the oldest models in
the data model which was developed by IBM, in the
1950s. In a hierarchical model, data are viewed as a
collection of tables, or we can say segments that form a
hierarchical relation. In this, the data is organized into a
tree-like structure where each record consists of one
parent record and many children. Even if the segments
are connected as a chain-like structure by logical
associations, then the instant structure can be a fan
structure with multiple branches. We call the illogical
associations as directional associations.
2. Network Model
The Network Model was formalized by the Database
Task group in the 1960s. This model is the
generalization of the hierarchical model. This model
can consist of multiple parent segments and these
segments are grouped as levels but there exists a
logical association between the segments belonging to
any level. Mostly, there exists a many-to-many logical
association between any of the two segments.
3. Object-Oriented Data Model
In the Object-Oriented Data Model, data and their
relationships are contained in a single structure which
is referred to as an object in this data model. In this,
real-world problems are represented as objects with
different attributes. All objects have multiple
relationships between them. Basically, it is a
combination of Object Oriented programming and a
Relational Database Model.
4. Float Data Model
The float data model basically consists of a two-
dimensional array of data models that do not contain
any duplicate elements in the array. This data model
has one drawback it cannot store a large amount of
data that is the tables can not be of large size.
5. Context Data Model
The Context data model is simply a data model which
consists of more than one data model. For example,
the Context data model consists of ER Model, Object-
Oriented Data Model, etc. This model allows users to
do more than one thing which each individual data
model can do.
6. Semi-Structured Data Model
Semi-Structured data models deal with the data in a
flexible way. Some entities may have extra attributes
and some entities may have some missing attributes.
Basically, you can represent data here in a flexible way.
Advantages of Data Models
1. Data Models help us in representing data
accurately.
 2. It helps us in finding the missing data and also in
minimizing Data Redundancy.
3. Data Model provides data security in a better way.
4. The data model should be detailed enough to be
used for building the physical database.
5. The information in the data model can be used for
defining the relationship between tables, primary
and foreign keys, and stored procedures.
Disadvantages of Data Models
1. In the case of a vast database, sometimes it
becomes difficult to understand the data model.
2. You must have the proper knowledge of SQL to use
physical models.
3. Even smaller change made in structure require
modification in the entire application.
4. There is no set data manipulation language in
DBMS.
5. To develop Data model one should know physical
data stored characteristics.
Conclusion
 Data modeling is the process of developing data
model for the data to be stored in a Database.
 Data Models ensure consistency in naming
conventions, default values, semantics, security
while ensuring quality of the data.
 Data Model structure helps to define the relational
tables, primary and foreign keys and stored
procedures.
 There are three types of conceptual, logical, and
physical.
 The main aim of conceptual model is to establish
the entities, their attributes, and their
relationships.
 Logical data model defines the structure of the
data elements and set the relationships between
them.
 A Physical Data Model describes the database
specific implementation of the data model.
 The main goal of a designing data model is to make
certain that data objects offered by the functional
team are represented accurately.
 The biggest drawback is that even smaller change
made in structure require modification in the
entire application.
Difference Between Hierarchical, Network and
Relational Data Model
In order to define the connections, organization, and
structure of data in a database management system
(DBMS), data models are essential. The effectiveness of
a database’s ability to store, retrieve, and alter data is
greatly influenced by the choice of data model. The
Hierarchical, Network, and Relational models are some
of the oldest types of data models; each has special
traits and applications. It is crucial to comprehend how
these models vary in order to choose the right one for
a given set of circumstances.
What is a Hierarchical Data Model?
The hierarchical data model is the oldest type of the
data model. It was developed by IBM in 1968. It
organizes data in a tree-like structure. Hierarchical
model consists of the following :
 It contains nodes which are connected by
branches.
 The topmost node is called the root node.
 If there are multiple nodes appear at the top level,
then these can be called root segments.
 Each node has exactly one parent.
 One parent may have many children.
In the above figure, Electronics is the root node which
has two children i.e. Televisions and Portable
Electronics. These two has further children for which
they act as parent. For example: Television has children
as Tube, LCD and Plasma, for these three Television act
as parent. It follows one to many relationship.
Advantages of the Hierarchical Data Model
 Because of its tree form, it is easy to grasp.
 Retrieving data in a one-to-many connection is
efficient.
Disadvantages of the Hierarchical Data Model
 Inflexibility in reorganizing data.
 accessing complicated data structures may be
challenging.
  redundant data storage, which might cause
anomalies and inconsistencies.
What is a Network Data Model?
It is the advance version of the hierarchical data model.
To organize data it uses directed graphs instead of the
tree-structure. In this child can have more than one
parent. It uses the concept of the two data structures
i.e. Records and Sets.

In the above figure, Project is the root node which has

two children i.e. Project 1 and Project 2. Project 1 has 3
children and Project 2 has 2 children. Total there are 5
children i.e Department A, Department B and
Department C, they are network related children as we
said that this model can have more than one parent.
So, for the Department B and Department C have two
parents i.e. Project 1 and Project 2.
Advantages of the Network Data Model
  Because of its numerous parent ties, it is more
adaptable than the hierarchical approach.
 Ideal for managing intricate, many-to-many
connections.
Disadvantages of the Network Data Model
 Increased complexity in database design and
management.
 requires complex programming in order to manage
and work with data.
What is a Relational Data Model?
The relational data model was developed by E.F. Codd
in 1970. There are no physical links as they are in the
hierarchical data model. Following are the properties of
the relational data model :
 Data is represented in the form of table only.
 It deals only with the data not with the physical
structure.
 It provides information regarding metadata.
 At the intersection of row and column there will be
only one value for the tuple.
 It provides a way to handle the queries with ease.
Advantages of the Relational Data Model
 High data independence and flexibility.
 offers robust and user-friendly querying features.
 removes duplication by use of normalization.
Disadvantages of the Relational Data Model
 For certain kinds of straightforward data retrieval
tasks, they may not perform as well as hierarchical
models.
 demands a deeper comprehension of SQL and
normalization principles.
Difference Between Hierarchical, Network and
Relational Data Model
Hierarchical Data Network Data Relational Data
Model Model Model

In this model, to It organizes

store data It organizes records in the
hierarchy records to one form of table
method is used. another through and relationship
It is the oldest links or between tables
method and not pointers. are set using
in use today. common fields.

It organizes
To organize It organizes
records in the
records, it uses records in the
form of directed
tree structure. form of tables.
graphs.

In addition to In addition to
It implements 1:1 and 1:n it 1:1 and 1:n it
1:1 and 1:n also implements also implements
relations. many to many many to many
relationships. relationships.

Pointers are A linked list is The logical

used to used to representation
establish establish a is used with
Hierarchical Data Network Data Relational Data
Model Model Model

rows and
relationships relationship columns to
among records among records depict
physically. physically. relationship
among records.

Insertion
anomaly exits in
this model i.e.
There is no There is no
child node
insertion insertion
cannot be
anomaly. anomaly.
inserted without
the parent
node.

Deletion
anomaly exists
There is no There is no
in this model i.e.
deletion deletion
it is difficult to
anomaly. anomaly.
delete the
parent node.
Hierarchical Data Network Data Relational Data
Model Model Model

Update leads to Updating a

inconsistency record is easy
problems No such and simple with
because of the problem as only the process of
existence of one instance of normalization,
multiple records exist. the redundant
instances of a data gets
child record. removed.

There is partial
This model lacks This model
data
data provides data
independence
independence. independence.
in this model.

No such facility No such facility SQL-based

for querying for querying declarative
database is database is querying is
supported. supported. supported.

It is used to It is used to It is used to

access the data access the data access the data
which is which is which is
Hierarchical Data Network Data Relational Data
Model Model Model

complex and complex and complex and

asymmetric. symmetric. symmetric.

Difficult to
design a
database and It is easy to
Difficult to manipulate a comprehend
design a database due to
database because of its concealed
because of its complexity. physical level
complexity. Hence, it details from
imposes a end-users.
burden on the
programmer.

It is flexible as It is flexible as
compared to compared to the
It is less flexible.
the hierarchical hierarchical
model. model.

&XML and VAX-DBMS, It is mostly used

XAML use this DMS-1100 of in real world
Hierarchical Data Network Data Relational Data
Model Model Model

UNIVAC and
applications.
model. SUPRADBMS’s
Oracle, SQL.
use this model.

What is Data Independence in DBMS?

In the context of a database management system, data
independence is the feature that allows the schema of
one layer of the database system to be changed
without any impact on the schema of the next higher
level of the database system. ” Through data
independence, we can build an environment in which
data is independent of all programs, and through the
three schema architectures, data independence will be
more understandable. Data via two card stencils along
with centralized DBMS data is a form of transparency
that has value for someone.
It can be summed up as a sort of immunity of user
applications that adjusts correctly and does not change
addresses, imparting the class of data and their order. I
want the separate applications not to be forced to deal
with data representation and storage specifics because
this decreases quality and flexibility. DBMS permits you
to see data with such a generalized sight. It actually
means that the ability to change the structure of the
lower-level schema without presenting the upper-level
schema is called data
independence.

Types of Data Independence

There are two types of data independence.
 logical data independence
  Physical data independence
Logical Data Independence
 Changing the logical schema (conceptual level)
without changing the external schema (view level)
is called logical data independence.
 It is used to keep the external schema separate
from the logical schema.
 If we make any changes at the conceptual level of
data, it does not affect the view level.
 This happens at the user interface level.
 For example, it is possible to add or delete new
entities, attributes to the conceptual schema
without making any changes to the external
schema.
Physical Data Independence
 Making changes to the physical schema without
changing the logical schema is called physical data
independence.
 If we change the storage size of the database
system server, it will not affect the conceptual
structure of the database.
 It is used to keep the conceptual level separate
from the internal level.
  This happens at the logical interface level.
 Example – Changing the location of the database
from C drive to D drive.
Difference Between Physical and Logical Data
Independence

Physical Data Logical Data

Independence Independence

It mainly concerns how It mainly concerns about

the data is stored in the changes to the structure
system. or data definition.

It is difficult to achieve
It is easier to achieve than
compared to physical
logical independence.
independence.

To make changes at the

To make changes at the
physical level we generally
logical level, we need to
do not require changes at
make changes at the
the application program
application level.
level.

It tells about the internal It tells about the

schema. conceptual schema.
Physical Data Logical Data
Independence Independence

Whenever the logical

There may or may not be structure of
a need for changes to be the database has to be
made at the internal level changed, the changes
to improve the structure. made at the logical level
are important.

Example- change in
compression Example –
technology, hashing adding/modifying or
algorithm, storage deleting a new attribute.
device etc.

Conclusion
The data independence property of the database is an
expected property that relies on separating the logical
and physical aspects of storing and accessing data. This
means that it is easy to make structural modifications
to the database without affecting the applications that
use it. This is a situation that impacts the capacity of
the organization to remain adaptable in the dynamic
business environment, as well as making sure that the
technological advancements within the organization
are interoperable over a long period of time.

Why is data independence important in database

management systems?
Data independence is important since it means that
modifications to the database schema at one level
need not result in the same at higher levels cascading
down. Scalability is a feature that allows an
organization to modify its system resources without
interrupting ongoing tasks when business needs
change or technological changes occur.

KEYS:
Keys are one of the basic requirements of a relational
database model. It is widely used to identify the
tuples(rows) uniquely in the table. We also use keys to
set up relations amongst various columns and tables of
a relational database.
Different Types of Database Keys
 Candidate Key
 Primary Key
 Super Key
  Alternate Key
 Foreign Key
 Composite Key
To master the concepts of keys and other essential
topics in databases, consider enrolling in the GATE CS
Self-Paced course . This course provides in-depth
coverage of core subjects, helping you build a strong
foundation for GATE and other competitive exams,
while enhancing your understanding of critical
computer science principles.
Candidate Key
The minimal set of attributes that can uniquely identify
a tuple is known as a candidate key. For Example,
STUD_NO in STUDENT relation.
 It is a minimal super key.
 It is a super key with no repeated data is called a
candidate key.
 The minimal set of attributes that can uniquely
identify a record.
 It must contain unique values.
 It can contain NULL values.
 Every table must have at least a single candidate
key.
  A table can have multiple candidate keys but only
one primary key.
 The value of the Candidate Key is unique and may
be null for a tuple.
 There can be more than one candidate key in a
relationship.
Example:
STUD_NO is the candidate key for relation STUDENT.
Table STUDENT

STUD_N SNAM ADDRES

O E S PHONE

12345678
1 Shyam Delhi
9

22336579
2 Rakesh Kolkata
6

17546896
3 Suraj Delhi
5

 The candidate key can be simple (having only one

attribute) or composite as well.
Example:
{STUD_NO, COURSE_NO} is a composite
candidate key for relation STUDENT_COURSE.
Table STUDENT_COURSE

STUD_N TEACHER_N COURSE_N

O O O

1 001 C001

2 056 C005

Note: In SQL Server a unique constraint that has a

nullable column, allows the value ‘ null ‘ in that
column only once . That’s why the STUD_PHONE
attribute is a candidate here, but can not be a ‘null’
value in the primary key attribute.
Primary Key
There can be more than one candidate key in relation
out of which one can be chosen as the primary key. For
Example, STUD_NO, as well as STUD_PHONE, are
candidate keys for relation STUDENT but STUD_NO can
be chosen as the primary key (only one out of many
candidate keys).
 It is a unique key.
 It can identify only one tuple (a record) at a time.
  It has no duplicate values, it has unique values.
 It cannot be NULL.
 Primary keys are not necessarily to be a single
column; more than one column can also be a
primary key for a table.
Example:
STUDENT table -> Student(STUD_NO, SNAME,
ADDRESS, PHONE) , STUD_NO is a primary key
Table STUDENT

STUD_N SNAM ADDRES

O E S PHONE

12345678
1 Shyam Delhi
9

22336579
2 Rakesh Kolkata
6

17546896
3 Suraj Delhi
5

Super Key
The set of attributes that can uniquely identify a tuple
is known as Super Key. For Example, STUD_NO,
(STUD_NO, STUD_NAME), etc. A super key is a group of
single or multiple keys that identifies rows in a table. It
supports NULL values.
 Adding zero or more attributes to the candidate
key generates the super key.
 A candidate key is a super key but vice versa is not
true.
 Super Key values may also be NULL.
Example:
Consider the table shown above.
STUD_NO+PHONE is a super key.

Relation between Primary Key, Candidate Key, and

Super Key
Alternate Key
The candidate key other than the primary key is called
an alternate key .
 All the keys which are not primary keys are called
alternate keys.
 It is a secondary key.
 It contains two or more fields to identify two or
more records.
 These values are repeated.
 Eg:- SNAME, and ADDRESS is Alternate keys
Example:
Consider the table shown above.
STUD_NO, as well as PHONE both,
are candidate keys for relation STUDENT but
PHONE will be an alternate key
(only one out of many candidate keys).
Primary Key, Candidate Key, and Alternate Key
Foreign Key
If an attribute can only take the values which are
present as values of some other attribute, it will be
a foreign key to the attribute to which it refers. The
relation which is being referenced is called referenced
relation and the corresponding attribute is called
referenced attribute. The referenced attribute of the
referenced relation should be the primary key to it.
 It is a key it acts as a primary key in one table and
it acts as
secondary key in another table.
 It combines two or more relations (tables) at a
time.
 They act as a cross-reference between the tables.
 For example, DNO is a primary key in the DEPT
table and a non-key in EMP
Example:
Refer Table STUDENT shown above.
STUD_NO in STUDENT_COURSE is a
foreign key to STUD_NO in STUDENT relation.
Table STUDENT_COURSE
STUD_N TEACHER_N COURSE_N
O O O

1 005 C001

2 056 C005

It may be worth noting that, unlike the Primary Key of

any given relation, Foreign Key can be NULL as well as
may contain duplicate tuples i.e. it need not follow
uniqueness constraint. For Example, STUD_NO in the
STUDENT_COURSE relation is not unique. It has been
repeated for the first and third tuples. However, the
STUD_NO in STUDENT relation is a primary key and it
needs to be always unique, and it cannot be null.

Relation between Primary Key and Foreign Key

Composite Key
Sometimes, a table might not have a single
column/attribute that uniquely identifies all the records
of a table. To uniquely identify rows of a table, a
combination of two or more columns/attributes can be
used. It still can give duplicate values in rare cases. So,
we need to find the optimal set of attributes that can
uniquely identify rows in a table.
 It acts as a primary key if there is no primary key in
a table
 Two or more attributes are used together to make
a composite key .
 Different combinations of attributes may give
different accuracy in terms of identifying the rows
uniquely.
Example:
FULLNAME + DOB can be combined
together to access the details of a student.
Different Types of Keys

What is a Strong Entity?

A strong entity is not dependent on any other entity in
the schema. A strong entity will always have a primary
key. Strong entities are represented by a single
rectangle. The relationship of two strong entities is
represented by a single diamond. Various strong
entities, when combined together, create a strong
entity set.
What is a Weak Entity?
A weak entity is dependent on a strong entity to ensure
its existence. Unlike a strong entity, a weak entity does
not have any primary key. It instead has a partial
discriminator key. A weak entity is represented by a
double rectangle. The relation between one strong and
one weak entity is represented by a double
diamond. This relationship is also known as
an identifying relationship.

Derived Attribute in DBMS

An entity is nothing but a piece of data that can be
uniquely identified in the database. For example, in a
university database, a student is an entity. The teacher
is also an entity as it can be uniquely identified.
Attributes
 Attributes are the properties of the entity.
Attributes are used to give more details about the
entity.
  Characteristics of an entity are stored in the
attributes only. Most of the time, attributes are
used to identify the instances of the attributes.
 An entity with zero attributes is of no use in the
database.
Example
Let’s take a student entity. Students will
have attributes such as roll number, name, class, etc.
So this can be represented as below.

 The entity is denoted in the rectangular box

whereas attributes are shown with the help of an
ellipse.
 In the above example, all attributes are placed in
ellipse whereas the student entity is shown with a
rectangular shape.
  There are many types of attributes present
in DBMS. We will study here about Derived
attributes only.
What is Derived Attribute?
Derived attributes are the attributes that can be
derived from the other attribute. These attributes are
not present in the database physically but they can be
derived from the other attributes easily. Derived
attributes are calculated on runtime, so it can be also
said that their values vary in nature.
Example
 Let’s take an example of a student entity only. Let’s
assume it has attributes such as roll number,
name, and DOB as shown in the figure.
 If we take another attribute which is age, we can
derive it from the DOB attribute. age need not be
present in the database. Derived attributes are
represented with the dotted ellipse as shown in
the figure.
Derived attribute

Let us understand it with values.

 We will take a student Table where we will have 3
attributes that are roll_no, name, and DOB.
 roll_no is used to identify every instance of the
given student entity.
 Here we need another attribute which is age. But
age is a derived attribute that can be derived from
the DOB attribute in the given student table.
Table Student

roll_no name DOB

1 kartik 01.01.2003

2 yash 01.01.2004
roll_no name DOB

adity
3 12.12.2003
a

 So using the DOB attributes we can derive the age

attribute easily. For example,
1. For roll_no 1, age = 21 years (age on the day
01.01.2024)
2. For roll_no 2, age = 20 years (age on the day
01.01.2024)
3. For roll_no 3, age = 20 years and 20 days (age on
the day 01.01.2024)
 Here we did not require the physical presence of
the age attribute in the database but we easily
derived it from the DOB attribute.
 So whenever we require the age of the student,
we will calculate the age from the DOB while
running the query.
 This will not require any extra memory to store the
age attributes in the system.
 These is called Derived Attributes.
What is a Unique Key?
Let’s consider one example of books in the library. In
the library, each book has a unique identification
number called ISBN(International Standard Book
Number). Just like how each book in the library has its
own ISBN which ensures that no two books are similar.
In the same way in the database of customers,
everyone has their unique email id so from that we can
get to know about that customer in detail. So these
examples illustrate the concept of unique identification
in a database system. So ISBN for the book and email ID
for a customer here work as a unique key.
Example:

Roll_no
. Name Address Personal_id

1 John Pune John@123

4 Merry Mumbai NULL

18 Sheero Nagpur 32467

20 Bisle Bengaluru B@127

In the above example, Roll_no can act as a primary
since it is unique and there is no null
value. Personal_id can act as a unique key because it is
also unique and for one time we can keep its value as
null so Personal_id is a unique key.

ntroduction of 3-Tier Architecture in DBMS – Set 2

Last Updated : 06 Nov, 2023


The 3-tier architecture is a commonly used

architectural approach in Database Management
Systems (DBMSs) for the design and development of
applications that work with databases. The 3-tier
architecture divides an application’s components into
three tiers or layers. Each layer has its own set of
responsibilities.
DBMS 3-Tier architecture divides the complete system
into three inter-related but independent modules as
shown below:
DBMS 3-tier architecture
 Physical Level: At the physical level, the
information about the location of database objects
in the data store is kept. Various users of DBMS are
unaware of the locations of these objects.In simple
terms,physical level of a database describes how
the data is being stored in secondary storage
devices like disks and tapes and also gives insights
on additional storage details.
 Conceptual Level: At conceptual level, data is
represented in the form of various database tables.
For Example, STUDENT database may contain
STUDENT and COURSE tables which will be visible
to users but users are unaware of their
 storage.Also referred as logical schema,it describes
what kind of data is to be stored in the database.
 External Level: An external level specifies
a view of the data in terms of conceptual level
tables. Each external level view is used to cater to
the needs of a particular category of users. For
Example, FACULTY of a university is interested in
looking course details of students, STUDENTS are
interested in looking at all details related to
academics, accounts, courses and hostel details as
well. So, different views can be generated for
different users. The main focus of external level is
data abstraction.
3 Tier Schema Architecture in DBMS
In DBMS, the 3-tier architecture is a client-server
architecture that separates the user interface,
application processing, and data management into
three distinct tiers or layers. The 3-tier architecture is
widely used in modern web applications and enterprise
systems because it offers scalability, flexibility, and
security. Here is a brief description of each tier in the 3-
tier architecture:
 Presentation Tier: The presentation tier is the user
interface or client layer of the application. It is
responsible for presenting data to the user and
 receiving input from the user. This tier can be a
web browser, mobile app, or desktop application.
 Application Tier: The application tier is the middle
layer of the 3-tier architecture. It is responsible for
processing and managing the business logic of the
application. This tier communicates with the
presentation tier to receive user input and
communicates with the data management tier to
retrieve or store data. This tier may include
application servers, web servers, or APIs.
 Data Management Tier: The data management
tier is the bottom layer of the 3-tier architecture. It
is responsible for managing and storing data. This
tier can include databases, data warehouses, or
data lakes. The data management tier
communicates with the application tier to receive
or store data.
Benefits of 3-Tier Architecture
The 3-tier architecture in DBMS provides several
benefits, including:
 Scalability: The architecture separates the
application processing and data management
layers, which allows for easy scalability of each
layer independently.
 Flexibility: The architecture allows for the
replacement or upgrade of one layer without
affecting the other layers.
 Security: The architecture provides an additional
layer of security, as the data management tier can
be isolated from the application and presentation
tiers, reducing the risk of unauthorized access.
Overall, the 3-tier architecture in DBMS is a flexible,
scalable, and secure approach to building modern web
applications and enterprise systems. It separates the
user interface, application processing, and data
management into distinct layers, providing clear
boundaries between each layer and improving system
performance, reliability, and maintainability.
Conclusion
In conclusion, a Database Management System (DBMS)
employs the 3-Tier Architecture, a tried-and-true
structure that separates an application into three main
layers: Presentation, Application Logic, and Data. This
architectural technique is increasingly popular for
creating dependable and maintainable software
systems that communicate with databases because it
improves the modularity, scalability, security,
reusability, and flexibility of applications.

ER MODEL
The Entity Relational Model is a model for identifying
entities to be represented in the database and
representation of how those entities are related. The
ER data model specifies enterprise schema that
represents the overall logical structure of a database
graphically.
The Entity Relationship Diagram explains the
relationship among the entities present in the
database. ER models are used to model real-world
objects like a person, a car, or a company and the
relation between these real-world objects. In short, the
ER Diagram is the structural format of the database.
Why Use ER Diagrams In DBMS?
 ER diagrams represent the E-R model in a
database, making them easy to convert into
relations (tables).
 ER diagrams provide the purpose of real-world
modeling of objects which makes them intently
useful.
 ER diagrams require no technical knowledge and
no hardware support.
 These diagrams are very easy to understand and
easy to create even for a naive user.
 It gives a standard solution for visualizing the data
logically.
A solid grasp of the ER Model is crucial for excelling in
exams like GATE, where database management is a key
topic. To enhance your understanding and boost your
exam preparation, consider the GATE CS Self-Paced
Course . This course offers in-depth coverage of the ER
Model and other essential database concepts, helping
you build the knowledge needed to succeed in your
exams.
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.
 Double Rectangle: Double Rectangle represents a
Weak Entity.

Symbols used in ER Diagram
Components of ER Diagram
ER Model consists of Entities, Attributes, and
Relationships among Entities in a Database System.

Components of ER Diagram
What is Entity?
An Entity may be an object with a physical existence – a
particular person, car, house, or employee – or it may
be an object with a conceptual existence – a company,
a job, or a university course.
What is Entity Set?
An Entity is an object of Entity Type and a set of all
entities is called an entity set. For Example, E1 is an
entity having Entity Type Student and the set of all
students is called Entity Set. In ER diagram, Entity Type
is represented as:

Entity Set
We can represent the entity set in ER Diagram but can’t
represent entity in ER Diagram because entity is row
and column in the relation and ER Diagram is graphical
representation of data.
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.
These are called Weak Entity types .
For 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 .
A weak entity type is 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.

Strong Entity and Weak Entity

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

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

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

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

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

Derived Attribute
The Complete Entity Type Student with its Attributes
can be represented as:
Entity and Attributes
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.
What is 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.
the total number of tables that can be used in this is 2.

one to one cardinality

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 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.
total number of tables that can used is 3.

one to many cardinality

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.
The total number of tables that can be used in this is 3.
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.
the total number of tables that can be used in this is 3.

many to many cardinality

Using Sets, it can be represented as:
Many-to-Many Set Representation
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 ER Diagram?
 The very first step is Identifying all the Entities, and
place them in a Rectangle, and labeling them
accordingly.
 The next step is to identify the relationship
between them and place them accordingly using
the Diamond, and make sure that, Relationships
are not connected to each other.
 Attach attributes to the entities properly.
 Remove redundant entities and relationships.
 Add proper colors to highlight the data present in
the database.
Conclusion
An Entity-Relationship (ER) model is a way to visually
represent the structure of a database. It shows how
different entities (like objects or concepts) are
connected and interact with each other through
relationships. The model uses diagrams to represent
entities as rectangles and relationships as diamonds,
making it easier to design and understand databases .