Department of Computer Engineering

Academic Year 2021-2022

Jay Patel: 60004210114 SE

Experiment No-1

Aim: Identify the case study and detail statement of problem. Design an Entity-Relationship
(ER) / Extended Entity-Relationship (EER) Model.

Theory:
Entity Relationship Diagrams are a major data modelling tool and will help organize the
data in your project into entities and define the relationships between the entities. This
process has proved to enable the analyst to produce a good database structure so that the
data can be stored and retrieved in a most efficient manner.

By using a graphical format it may help communication about the design between the
designer and the user and the designer and the people who will implement it.
Components of an ERD
An ERD typically consists of four different graphical components:
1. Entity.
A data entity is anything real or abstract about which we want to store data. Entity
types fall into five classes: roles, events, locations, tangible things or concepts. E.g.
employee, payment, campus, book. Specific examples of an entity are called
instances. E.g. the employee John Jones, Mary Smith's payment, etc.
2. Relationship.
A data relationship is a natural association that exists between one or more
entities. E.g. Employees process payments.
3. Cardinality.
Defines the number of occurrences of one entity for a single occurrence of the
related entity. E.g. an employee may process many payments but might not
process any payments depending on the nature of her job.
4. Attribute.
A data attribute is a characteristic common to all or most instances of a particular
entity. Synonyms include property, data element, and field. E.g. Name, address,
Employee Number, pay rate are all attributes of the entity employee. An attribute or
combination of attributes that uniquely identifies one and only one instance of an
entity is called a primary key or identifier. E.g. Employee Number is a primary key
for Employee.

A Simple Example

1
 Department of Computer Engineering
Academic Year 2021-2022

The above process will be illustrated by working through the following example.
A company has several departments. Each department has a supervisor and at least one
employee. Employees must be assigned to at least one, but possibly more departments. At
least one employee is assigned to a project, but an employee may be on vacation

and not assigned to any projects. The important data fields are the names of the
departments, projects, supervisors and employees, as well as the supervisor and
employee number and a unique project number.
Each of the following sections corresponds to one of the stages above.

Identify entities

In this stage, you look through the information about the system and seek to identify the
roles, events, locations, concepts and other tangible things that you wish to store data about.
One approach to this is to work through the information and highlight those words which you
think correspond to entities.
A company has several departments. Each department has a supervisor and at least one
employee. Employees must be assigned to at least one, but possibly more departments. At
least one employee is assigned to a project, but an employee may be on vacation and not
assigned to any projects. The important data fields are the names of the departments,
projects, supervisors and employees, as well as the supervisor and employee number and a
unique project number.
This example is quite simple in that the last couple of lines actually tell you what data is
being stored and that makes it somewhat easy to identify the entities.
You may notice that "company" has been highlighted. It is not an example of an entity. A
single company will use the system we are designing to keep track of its departments,
projects, supervisors and employees.
A true entity should have more than one instance. Our system will probably contain
information about multiple employees, supervisors, projects and departments. But it will only
contain one instance of a company.

Cardinality: A number that represents, one instance of first entity(table) is related to how
many instances of the second entity, is known as cardinality. Cardinality is a relationship or
join/bridge between rows of 1 table to the rows of another table.

There are three types of cardinalities in DBMS-

1) One to One (1:1): One instance of first entity can relate to only one instance of
another entity. For example, one User can only have one profile associated to them and not
more than that.
2) One to Many (1:M): One instance of first entity can relate to multiple instances of
another entity but it cannot be the other way around. For example, one user can create
multiple posts, but one post cannot be created by multiple users.

2
 Department of Computer Engineering
Academic Year 2021-2022

3) Many to Many (M:N): Multiple instances of first entity can relate to multiple entities
of another entity. For example, many users can comment on the same post and one user can
also comment on multiple posts.
Participation: Participation constraint specifies the existence of an entity when it is related to
another entity in a relationship type. It is also called minimum cardinality constraint. This
constraint specifies the number of instances of an entity that can participate in a relationship
type.

Relation: There are several implicit relationships among the various entity types. In fact,
whenever an attribute of one entity type refers to another entity type, some relationship exists.

Different notations on ER Diagram:

3
 Department of Computer Engineering
Academic Year 2021-2022

Case Study Description:

1) The Entity Canteen represent the attributes such as Menu, Food, Bill No, where Bill
No is the primary key.
2) The Entity Library represent the attributes such as Book id, Book name, No of
books , Departments where Book id is the primary and Department name.
3) The Entity Department has attributes such as D_id , department name and no of
students
4) The Entity Principal is a weak entity has attributes such name, age, qualification
where name is the primary attributes
5) The Entity staff has attributes such as staff no, staff name and salary where staff no is
prime attribute
6) The Student entity has attributes such as student id, name, age, DOB where student id
is a prime attribute
7) The Exam entity has attribute such as Subject, Exam Date, Marks, Course no where
course no is the prime attribute.

Entities:

Student – id, name, age, DOB

Canteen- Bill no, menu, price

Library- Book id, book name, no of books, departments

Staff- staff no, staff name, salary

Exam- Course no, subject, date, marks

Departments- d_id, d_name

Principal - age, name, qualification

Cardinality ERD notation

4
 Department of Computer Engineering
Academic Year 2021-2022

Cardinality Constraints:
1) College to department have one to many cardinality as one college can have multiple
department but one department of a college cannot belong to multiple college
2) College to canteen have one to one cardinality as one college can have one college
and vice versa
3) College to student have one to many cardinality as one college can have many
students but one student cannot belong to many college
4) College to staff have many to many cardinality as one college can have multiple staff
and vice versa
5) College to library have one to many cardinality as one college can have multiple
library but one library does not belong to more than one college
6) College to exam have one to many cardinality as one college can conduct multiple
exam but one exam cannot be conducted by multiple college
7) Staff to principal have one to one cardinality as there should be only one principal in a
staff and one principal should belong to only one college staff

5
 Department of Computer Engineering
Academic Year 2021-2022

Complete ER Diagram for College Management: -

Conclusion: Entity Relationship Modeling is a graphical approach to database design. It

uses Entity/Relationship to represent real world objects. It is better to design E-R model
before going for implementation of any project.