BCA/BSC

Semester-2
Database & Security (Unit-2)

The Entity Relational 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 an enterprise schema
that represents the overall logical structure of the 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.

Use of ER Diagrams in DBMS

● ER diagrams are used to represent the E-R model in a database, which makes them easy
to be converted 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 an end user.
● It gives a standard solution for visualizing the data logically.

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

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 don’t have existed 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

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 the ER diagram, the
attribute is represented by an oval.

Attribute

1. 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 the ER
diagram, the composite attribute is represented by an oval comprising of ovals.

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

Entity-Relationship Diagram

E-R Diagram is known as Entity-Relationship Diagram, it is used to analyse the structure of the
Database. It shows relationships between entities and their attributes. An ER Model provides a
means of communication.

The Library Management System database keeps track of readers with the following
considerations –

● The system keeps track of the staff with a single point authentication system comprising
login Id and password.
● Staff maintains the book catalog with its ISBN, Book title, price(in INR),
category(novel, general, story), edition, author Number and details.
● A publisher has publisher Id, Year when the book was published, and name of the book.
● Readers are registered with their user_id, email, name (first name, last name), Phone no
(multiple entries allowed), communication address. The staff keeps track of readers.
● Readers can return/reserve books that stamps with issue date and return date. If not
returned within the prescribed time period, it may have a due date too.
● Staff also generate reports that has readers id, registration no of report, book no and
return/issue info.
E-R Diagram For Library Management System
This Library ER diagram illustrates key information about the Library, including entities such as
staff, readers, books, publishers, reports, and authentication system. It allows for understanding the
relationships between entities.

Entities and their Attributes –

● Book Entity : It has authno, isbn number, title, edition, category, price. ISBN is the
Primary Key for Book Entity.
● Reader Entity : It has UserId, Email, address, phone no, name. Name is a composite
attribute of firstname and lastname. Phone no is a multi valued attribute. UserId is the
Primary Key for Readers entity.
● Publisher Entity : It has PublisherId, Year of publication, name. PublisherID is the
Primary Key.
● Authentication System Entity : It has LoginId and password with LoginID as Primary
Key.
● Reports Entity : It has UserId, Reg_no, Book_no, Issue/Return date. Reg_no is the
Primary Key of reports entity.
● Staff Entity : It has a name and staff_id with staff_id as Primary Key.
● Reserve/Return Relationship Set : It has three attributes: Reserve date, Due date,
Return date.

Relationship between Entities –

● A reader can reserve N books but one book can be reserved by only one reader. The
relationship 1:N.
● A publisher can publish many books but a book is published by only one publisher. The
relationship 1:N.
● Staff keeps track of readers. The relationship is M:N.
● Staff maintains multiple reports. The relationship 1:N.
● Staff maintains multiple Books. The relationship 1:N.
● Authentication system provides login to multiple staffs. The relation is 1:N.
 ER Diagram of Bank Management System
ER diagram of Bank has the following description :

● Bank have Customer.

● Banks are identified by a name, code, address of main office.
● Banks have branches.
● Branches are identified by a branch_no., branch_name, address.
● Customers are identified by name, cust-id, phone number, address.
● Customer can have one or more accounts.
● Accounts are identified by account_no., acc_type, balance.
● Customer can avail loans.
● Loans are identified by loan_id, loan_type and amount.
● Account and loans are related to bank’s branch.

This bank ER diagram illustrates key information about bank, including entities such as branches,
customers, accounts, and loans. It allows us to understand the relationships between entities.

Entities and their Attributes are :

● Bank Entity : Attributes of Bank Entity are Bank Name, Code and Address.
Code is Primary Key for Bank Entity.
● Customer Entity : Attributes of Customer Entity are Customer_id, Name, Phone
Number and Address.
Customer_id is Primary Key for Customer Entity.
● Branch Entity : Attributes of Branch Entity are Branch_id, Name and Address.
Branch_id is Primary Key for Branch Entity.
● Account Entity : Attributes of Account Entity are Account_number, Account_Type and
Balance.
Account_number is the Primary Key for Account Entity.
● Loan Entity : Attributes of Loan Entity are Loan_id, Loan_Type and Amount.
Loan_id is Primary Key for Loan Entity.
ER Diagram of Bank Management System

● Bank has Branches => 1 : N

One Bank can have many Branches but one Branch can not belong to many Banks, so
the relationship between Bank and Branch is one to many relationship.

● Branch maintain Accounts => 1 : N

One Branch can have many Accounts but one Account can not belong to many
Branches, so the relationship between Branch and Account is one to many relationship.

● Branch offer Loans => 1 : N

One Branch can have many Loans but one Loan can not belong to many Branches, so
the relationship between Branch and Loan is one to many relationship.

● Account held by Customers => M : N

One Customer can have more than one Accounts and also One Account can be held by
 one or more Customers, so the relationship between Account and Customers is many to
many relationship.

● Loan availed by Customer => M : N

(Assume loan can be jointly held by many Customers).
One Customer can have more than one Loans and also One Loan can be availed by one
or more Customers, so the relationship between Loan and Customers is many to many
relationship.

Cardinality
Cardinality means how the entities are arranged to each other or what is the relationship structure
between entities in a relationship set. In a Database Management System, Cardinality represents a
number that denotes how many times an entity is participating with another entity in a relationship
set. There is another term that determines the type of Relationship among Entities in DBMS
which is called Cardinality

Mapping Cardinality, which represents the mapping of one entity set to another entity set in a
relationship set. We generally take the example of a binary relationship set where two entities are
mapped to each other.
Cardinality is very important in the Database of various businesses. For example, if we want to
track the purchase history of each customer then we can use the one-to-many cardinality to find the
data of a specific customer. The Cardinality model can be used in Databases by Database Managers
for a variety of purposes, but corporations often use it to evaluate customer or inventory data.
There are four types of Cardinality Mapping in Database Management Systems:
1. One to one
2. Many to one
3. One to many
4. Many to many
One-to-One (1:1)

One-to-One Cardinality is found when one occurrence of an Entity is associated with exactly one
occurrence of another Entity. For example, if a person and passport are two identities, then one
person can have exactly one passport and only one passport can be assigned to a person.

One-to-Many (1:N)

This cardinality in DBMS relates one occurrence of an Entity to multiple occurrences of another
entity. One-to-Many Cardinality can be observed in the database when one row of a table is related
to many rows of another table. For example, one teacher can teach many students at a time. But,
many teachers cannot teach a single student at a time. Hence, this is One-to-Many Cardinality.

Many-to-One (N:1)
When Many occurrences of an Entity are associated with a single occurrence of another Entity, it is
termed a Many-to-One Cardinality in DBMS. This means that many rows of a table are related to a
single row of another table. An example of this Cardinality is surgeries done by a doctor. Many
surgeries can be performed by a single doctor. But one surgery cannot be performed by many
doctors at a time.
Many-to-Many (N: N)
This cardinality in DBMS is found when multiple occurrences of one Entity are related to Multiple
Occurrences of another Entity. In other words, multiple rows of a table are related to multiple rows
of another table. For example, in an IT company, many software engineers can work on many
projects, and many projects can be handled by multiple people in the company.

Keys
Keys play an important role in the relational database. 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.

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.

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.