Database management system

Unit - 2

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

Notation of ER diagram
Database can be represented using the notations. In ER diagram, many
notations are used to express the cardinality. These notations are as follows:
Introduction of ER Model
Peter Chen developed the ER diagram in 1976. The ER model was created to
provide a simple and understandable model for representing the structure and
logic of databases. It has since evolved into variations such as the Enhanced
ER Model and the Object Relationship 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.