Unit 3

Entity in DBMS
Database Management System (DBMS) is an essential tool to manage
data, but do you know how important entities are in DBMS?
The role of the entity is the representation and management of data. In
this article, we are going to discuss entities in DBMS.

Entity:
An entity is referred to as an object or thing that exists in the real world.
For example, customer, car, pen, etc.
Entities are stored in the database, and they should be distinguishable,
i.e., they should be easily identifiable from the group. For example, a
group of pens that are from the same company cannot be identified, so
they are only objects, but pens with different colours become unique and
will be called an entity like a red pen, green pen, blue pen, black pen, etc.
In a group of pens, we can easily identify any pen because of its different
colours, so a pen of different colours is an entity.
For extracting data from the database, each data must be unique in its
own way so that it becomes easier to differentiate between them. Distinct
and unique data is known as an entity.
An entity has some attributes which depict the entity's characteristics. For
example, an entity "Student" has attributes such as "Student_roll_no",
"Student_name", "Student_subject", and "Student_marks".
Example of Entity in DBMS in tabular form:
Student_rollno Student_name Student_subject Student_marks

1 Robert English 85
 2 Parker Mathematics 75

3 Harry Science 80

4 George Geography 70
Some entities are related to other entities in the table. For example, the
"Student" entity is related to the "University" entity. The ERD (Entity
Relationship Diagram) model comes to light to visually show the
relationship between several entities.
Kinds of Entity:
There are two kinds of entities, which are as follows:
1. Tangible Entity:
It is an entity in DBMS, which is a physical object that we can touch or
see. In simple words, an entity that has a physical existence in the real
world is called a tangible entity.
For example, in a database, a table represents a tangible entity because
it contains a physical object that we can see and touch in the real world. It
includes colleges, bank lockers, mobiles, cars, watches, pens, paintings,
etc.
2. Intangible Entity:
It is an entity in DBMS, which is a non-physical object that we cannot see
or touch. In simple words, an entity that does not have any physical
existence in the real world is known as an intangible entity.
For example, a bank account logically exists, but we cannot see or touch
it.
Entity Type:
A collection of entities with general characteristics is known as an entity
type.
For example, a database of a corporate company has entity types such as
employees, departments, etc. In DBMS, every entity type contains a set of
attributes that explain the entity.
The Employee entity type can have attributes such as name, age,
address, phone number, and salary.
The Department entity type can have attributes such as name, number,
and location in the department.
Kinds of Entity Type
There are two kinds of entity type, which are as follows:
1. Strong Entity Type: It is an entity that has its own existence and is
independent.
The entity relationship diagram represents a strong entity type with the
help of a single rectangle. Below is the ERD of the strong entity type:
In the above example, the "Customer" is the entity type with attributes
such as ID, Name, Gender, and Phone Number. Customer is a strong
entity type as it has a unique ID for each customer.
2. Weak Entity Type: It is an entity that does not have its own existence
and relies on a strong entity for its existence.
The Entity Relationship Diagram represents the weak entity type using
double rectangles. Below is the ERD of the weak entity type:
In the above example, "Address" is a weak entity type with attributes
such as House No., City, Location, and State.
The relationship between a strong and a weak entity type is known as an
identifying relationship.
Using a double diamond, the Entity-Relationship Diagram represents a
relationship between the strong and the weak entity type.
Let us see an example of the relationship between the Strong entity type
and weak entity type with the help of ER Diagram:
Entity Set
An entity set is a group of entities of the same entity type.
For example, an entity set of students, an entity set of motorbikes, an
entity of smartphones, an entity of customers, etc.
Entity sets can be classified into two types:
1. Strong Entity Set:
In a DBMS, a strong entity set consists of a primary key.
For example, an entity of motorbikes with the attributes, motorbike's
registration number, motorbike's name, motorbike's model, and
motorbike's colour.
Below is the representation of a strong entity set in tabular form:
Example of Entity Relationship Diagram representation of the above
strong entity set:
2. Weak Entity Set:
In a DBMS, a weak entity set does not contain a primary key.
For example, An entity of smartphones with its attributes, phone's name,
phone's colour, and phone's RAM.
Below is the representation of a weak entity set in tabular form:
Example of Entity Relationship Diagram representation of the above weak
entity set:
 Explain attributes and the
different types of attributes in
DBMS?
Attributes are the properties which describe an entity.
Example
The attributes of student entity are as follows −
 Roll number
 Name
 Branch
 Age
Types of attributes
The different types of attributes are as follows −
Composite attribute
It can be divided into smaller sub parts, each sub part can form an
independent attribute.
For example −
Name
FirstName MiddelName LastName
Simple or Atomic attribute
Attributes that cannot be further subdivided are called atomic attributes.
For example −
Phone number
PIN code

Single valued Attribute

Attributes having a single value for a particular item is called a single valued
attribute.
For example: Room Number

Multi-valued Attribute
Attribute having a set of values for a single entity is called a multi-valued
attribute.
For example −
e-mail
Tel.No
Hobbies

Derived Attributes or stored Attributes

When one attribute value is derived from the other is called a derived
attribute.
For example: Age can be derived from date of birth, where,
 Age is the derived attribute.
 DOB is the stored attribute.

Complex Attribute
Nesting of composite and multi-valued attributes forms a complex attribute.
For example
If a person has more than one house and each house has more than one
phone. Then, that attribute phone is represented as a complex attribute.
Keys
o Keys play an important role in the relational database.
o It is used to uniquely identify any record or row of data from the
table. It is also used to establish and identify relationships between
tables.
For example, ID is used as a key in the Student table because it is
unique for each student. In the PERSON table, passport_number,
license_number, SSN are keys since they are unique for each person.
Types of keys:

1. Primary key
o It is the first key used to identify one and only one instance of an
entity uniquely. An entity can contain multiple keys, as we saw in
the PERSON table. The key which is most suitable from those lists
becomes a primary key.
o In the EMPLOYEE table, ID can be the primary key since it is unique
for each employee. In the EMPLOYEE table, we can even select
License_Number and Passport_Number as primary keys since they
are also unique.
o For each entity, the primary key selection is based on requirements
and developers.
2. Candidate key
o A candidate key is an attribute or set of attributes that can uniquely
identify a tuple.
o Except for the primary key, the remaining attributes are considered
a candidate key. The candidate keys are as strong as the primary
key.
For example: In the EMPLOYEE table, id is best suited for the primary
key. The rest of the attributes, like SSN, Passport_Number,
License_Number, etc., are considered a candidate key.

3. Super Key
Super key is an attribute set that can uniquely identify a tuple. A super
key is a superset of a candidate key.
For example: In the above EMPLOYEE table, for(EMPLOEE_ID,
EMPLOYEE_NAME), the name of two employees can be the same, but their
EMPLYEE_ID can't be the same. Hence, this combination can also be a
key.
The super key would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME),
etc.
4. Foreign key
o Foreign keys are the column of the table used to point to the
primary key of another table.
o Every employee works in a specific department in a company, and
employee and department are two different entities. So we can't
store the department's information in the employee table. That's
why we link these two tables through the primary key of one table.
o We add the primary key of the DEPARTMENT table, Department_Id,
as a new attribute in the EMPLOYEE table.
o In the EMPLOYEE table, Department_Id is the foreign key, and both
the tables are related.
5. Alternate key
There may be one or more attributes or a combination of attributes that
uniquely identify each tuple in a relation. These attributes or combinations
of the attributes are called the candidate keys. One key is chosen as the
primary key from these candidate keys, and the remaining candidate key,
if it exists, is termed the alternate key. In other words, the total number
of the alternate keys is the total number of candidate keys minus the
primary key. The alternate key may or may not exist. If there is only one
candidate key in a relation, it does not have an alternate key.
For example, employee relation has two attributes, Employee_Id and
PAN_No, that act as candidate keys. In this relation, Employee_Id is
chosen as the primary key, so the other candidate key, PAN_No, acts as
the Alternate key.

6. Composite key
Whenever a primary key consists of more than one attribute, it is known
as a composite key. This key is also known as Concatenated Key.
For example, in employee relations, we assume that an employee may
be assigned multiple roles, and an employee may work on multiple
projects simultaneously. So the primary key will be composed of all three
attributes, namely Emp_ID, Emp_role, and Proj_ID in combination. So
these attributes act as a composite key since the primary key comprises
more than one attribute.

7. Artificial key
The key created using arbitrarily assigned data are known as artificial
keys. These keys are created when a primary key is large and complex
and has no relationship with many other relations. The data values of the
artificial keys are usually numbered in a serial order.
For example, the primary key, which is composed of Emp_ID, Emp_role,
and Proj_ID, is large in employee relations. So it would be better to add a
new virtual attribute to identify each tuple in the relation uniquely.
Relationship among entities.
A relationship is represented by diamond shape in ER diagram, it shows
the relationship among entities. There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

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

2. One to Many Relationship

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

3. Many to One Relationship

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

ervices