Shirpur Education Society’s

R. C. PATEL INSTITUTE OF TECHNOLOGY

Nimzari Naka, Shirpur- 425 405 Dist : Dhule (MS)

Department of Computer Engineering & Information Technology

Laboratory Manual
Subject:- Database Management System (DBMS)
Class:-T.E.Computer Semester-II

Experiment No:-02

Aim:- Prepare Entity-Relationship diagram for given application

Software requirement: - Microsoft word or Paint.

Theory: -
Real World Object in the database
we talked about “structure” and “instance” of a structure. A model is a higher level name of a structure.
A structure is a more formal representation of a model. For example “structure of a house” and “model of a
house” represent the same thing but the structure gives more information about the construction of the house
compared to its model.
Mini world Example: Company

System
independent Component identification Example: Departments, location, etc.
steps
Example: How communication flows
How components are related? among departments.

Data collection about components Example: Size, type, location, etc.

Example: Illustration of
Conceptual design components and which is related
to what and how.
Outcome: A semantic model of
Conceptual schema
the miniworld

System
Example: How the model is
dependent
steps Data model mapping mapped to a logical structure
which can be stored in the
database.
 Any object or entity has its own structure. For example, a table or a chair or a human being has a
unique structure. The process uses a tool which describes the entity in terms of smaller components and its
semantics. For example, the model of a chair must describe its semantics (e.g., it is an entity where people sit)
and must identify smaller components (legs, back, etc.) and their inter-relationship. Such modeling tools are
called “Semantic Data Modeling”. One such tools, which is referred to as “Entity-Relationship” model.

A database modeling can be illustrated by the above diagram:

Mini world: A part of the real world for which you design a database. Our example: A Company. The
company performs a set of functions through a number of departments. The company can be a bank, a
manufacturing plant, or an airline. We describe the structure of the company in terms of a number of
components.
Component identification: The company has a set of departments = {D1, D2, ..., Dn}. Each department has a
specific role, specific function, and can be identified by a set of attributes. The company may have a number of
branches which may be located at various locations. Each branch may have its own set of departments; thus the
structure is identical.
How components are related: Department D1 may or may not be dependent on department D2. If dependent
then the existence of D1 will dependent on the existence of D2. If D2 closes then D1 must close as well. For
example if the production department of a company closes down the sales department must also go.
Data collection: To identify and deal with a department a set of meaningful attributes for each department is
selected. Some example attributes are: Dname, Dnumber, Dmanager, Dmanager Start date, Dept. locations,
etc. Each department has specific functions. For example sales department has some specific functions,
production department has a set of functions such as projects, completion date of each project, and so on.
Necessary data about these function-sets must be collected.
Conceptual design: A semantic modeling tool uses above information to build a model of the company. A
good model is able to answer questions such as (a) How many departments are in this company, (b) What is the
name of the company, (c) What the projects manages by this company, (d) What is the function of sales
department, and so on. These components are related to each other in a variety of ways. A relationship can be
categorized into (a) One to one (1:1), (b) One to many (1:N), and (b) Many to many (M:N).
One to One (1:1): The instance of one entity is related to only one instance of another entity with some
relationship type. For example, one employee works in one department. The association of the employee with
the department is 1:1.
One to Many (1:N): An instance of an entity (E) is related with only one instance of another entity (F) but F is
related to many instances of E.
Many to Many (M:N): An instance of an entity E is related to many instances of entity F and one instance of
F is related to many instances of E.

1-to-1 1-to-Many Many-to-1 Many-to-Many

Entity-Relationship Model
We first learn essential terms of this modeling technique.
• Entity: The basic object. This object may not be further divided into smaller meaningful objects.
Example: Employee, car, dog, people, etc.
• Entity type: Every entity has a type. It identifies an entity and its placement in the real world. For example, entity
type CAR, which identifies an entity which has a set of special properties.
• Attribute: Identifies a property of an entity. For example, with the set of attributes such as, color, registration ID,
make, manufacturer, etc., we may know the object is a car but we would not know which car (car model).
Mathematically, an attribute A with value set V of entity type E can be defined as a function from E to the
power set of V: A:E → P (V). This indicates that value of A comes from power set V. This means, A may have
multiple values or it may have only one value or may have no value, i.e., null.
• Value: Each attribute has a value. An instance of an entity is a mapping from attribute to its value. For
example, when we assign value to color, registration ID and make, then we identify a unique car.
• Value set (Domain) of attributes: The instance of an entity comes into existence when allowed values are
assigned to the attributes of this entity. In order to represent a fact, a value of an attribute comes from a set of
values. Such a set whose members can be assigned to an attribute to represent a fact is called attribute domain or value set.
• Attribute hierarchy: An attribute of an object may be made up of several smaller attributes. This means a big
attribute may be identified by a set of smaller attributes. In turn, a smaller attribute may be identified by a set of
smallest attributes. In this way we could create a hierarchy, which would describe the main attribute. The leaves
of this hierarchy cannot be further divided meaningfully, so they are called atomic or simple attributes.
• Single-valued attribute: A single valued attribute can take only one value for an object. Example: employee's
age. You cannot assign two different age values to the same employee.
• Multi-valued attribute: A multi-valued attribute can take a number of values. Example: color of an entity
(e.g., car, house) can take value as red, black, and white. Note that the attribute must belong to the same entity.
• Derived attribute: If the value of an attribute can be obtained from the value(s) of another attribute(s) then
the former is called a derived attribute. Example: Age is derivable from the date of birth and current date.
• Key attribute: An attribute or a set of attributes whose value(s) identify uniquely an instance of entity
instance. eg: SSN, vehicle ID, etc.

Relationship Types and Relationship Instances

We can treat a relationship type as an object too. Attributes can be assigned to a relationship
type. Assignment of values to these attributes will create instances of a relationship type. We can
define a relationship type R as follows:
ri = Works_For is a relationship between two entities (Employee and Department).
Employee instances Work_For Instances Department Instances

d1
e1 r1
e2
d2
r2
e3 d3
r3
e4 r4
. .

Instances of relationship type Work_for, Employee, and Department and their relationship
Degree of a Relationship Type
In reality (a) only two entities are related together or (b) more than two entities are related
together. This kind of situation is defined by “degree of a relationship” type. Thus, it defines
how many entity types are related with a relationship type.
Binary relation: In this relationship type only two entity types are related with a relationship
type.
Example: entity type Employee and entity type Department are related with Works_For
relationship type. Note that only Employee and Department entities are involved in this relation,
there is no third entity.
Ternary relation: In this relationship type, three entities (not two and not four) are related with
a relationship type.

Example 1
Entity types: Supplier (S), Part (P), and Project (J).
Relationship types: Uses and Supplies

Binary relationship instances:

(S1, P1) - S1 Supplies part P1.
(J1, P1) - Project J1 Uses part P1.
(S1, J1) - Supplier S1 Supplies some parts to project J1.
Ternary relationship instances:
(S1, J1, P1) - Supplier S1 Supplies part J1 to project P1.
Role Names and Recursive Relationship
In some relationship types, the related entities are independent in their function. For example:
Supplier---------- Supplies ---------- Parts.
Supplier entity type and Parts entity type do not have anything in common. In such relationship
types, Supplier plays the role of supplier and Parts the role of parts. In cases where several
entity types have some common attributes and play multiple roles. For example,
Supervisor ---------- Supervises ---------- Employees.
In this relationship type we have two entities “Supervisor” and Employees. From company’s
administration viewpoint Supervisor is an employee and thus its attributes are the same as
“Employees” attribute. However, an Employee is identified as a “Supervisor” because a special
role is assigned to this employee. Note that the “Role” can be used as an attribute. In these kind
of situations, it is said that “Employees” is related to “Employees” recursively and the
relationship type is called recursive. Review: give an example of a recursive relationship type in
University entity type.

Constraints on Relationship Types

As mentioned earlier, a relationship type can be binary, ternary, etc. We represent these
properties in terms of the following (a) Cardinality ratio (b) Participation
Cardinality ratio: Number of instances of an entity that can participate in the instance of
another entity. For example
Employee ---------- Works_For ----------Department.
If we say that several employees works for a department then this would mean: One instance of
department type is related to several instances of employee type. So the cardinality ratio of this
relationship is 1:N. Cardinality ratios for a binary relationship type: 1:1, 1:N, M:N.

Participation constraint: Specifies that the existence of an entity type depends on the existence
of another related entity type. This constraint exists in two ways: (a) Total participation and (b)
Partial participation.
Total participation: This participation exists when all instances of an entity type are related to
one instance of an entity type. For example, every employee works_for a department. Thus, an
employee exists only if a department exists. So the participation of an employee is total in
works_for relationship. Review: Give another example of total participation between entity
types“Project” and “Department”.
Partial participation: This participation exists when one of the instances of an entity type is
related to an instance of another entity type. For example, one of the employees (Manager)
manages a department. It is not true that every employee manages a department. This implies
that the existence of an employee type does not necessarily mean the existence of manages
relationship for the employee. So the participation of an employee in manages is partial.
Together Cardinality ratio and Participation constraints are termed as Structural
Constraints.

Attributes of Relationship Type

A relationship type can be treated as an entity and, therefore, it may have some attributes. For
example, relationship type Manages can have an attribute Start_date. In 1:1 cardinality ratio, the
attribute of a relationship type may also be regarded as an attribute of the related entity type. For
example in Employee ---------- Manages ---------- Department. Start_date can be an attribute of
an employee (manager) or of the department he manages.
For relationship type Works_For with attribute Start_date (cardinality ratio: 1:N - one
department many employees) the attribute Start_date can only be included on the N side of the
relationship. For example, in Employee ---------- Works_For ---------- Department Start_date
cannot serve as an attribute of Department since it would not be meaningful.
For relationship type Works_On with attribute Hours (cardinality ratio: M:N - many projs
many emps) the situation is different. The attribute of a relationship type may not be the attribute
of any of the participating entity types but the value of the attribute is determined by both the
entity types. For example, in Employee ---------- Works_on ---------- Project the attribute of
Works_on is Hours. It may not be meaningful to make Hours as an attribute of the employee
or/and of Project. In this kind of situation the attribute is associated with the relationship type.

Weak Entity Type

The existence of weak entity types depends upon the existence of identifying owner entity
type. For example, Employee and Dependents. The existence of dependent type (Dependent)
depends on the existence of employee type. Therefore, Dependent is a weak entity type. This
needs further clarification. The dependent entity must require the existence of the parent entity.
Take the case of “Employee” and “Department”. When a new department is created then there is
no employee so neither is a week entity. How about department and project? A project must be
handled by a department. If there is no department then there is no project. If the production
department is gone then all the project it manages must also go. What about entity type Car and
entity type Driver? Is any one a weak entity type? What about entity type Shop and entity type
Customer? Which one do you think is a weak entity or none is a weak entity? Review: Give two
more example of weak entity type in entity type University.
Refinement of the Company database
We will apply all these concepts to refine the design of our simple company database. First let us
identify the relationship types:
• Manages: An employee manages a department. So there is one manager with one
department.
Cardinality ratio: 1:1.
Employee participation: Weak since only one out of several employees manage one
department.
Department participation: Total. A department must be associated with a manager.
• Works_for: One employee to one department but a department has many employees.
Cardinality ratio: 1:N.
Department and employee participations: Total.
• Controls: One project to only one department but a department controls many projects.
Cardinality ratio: 1:N (Department to Projects)
Department participation: Partial. A department may not have any project.
Project participation: Total. All projects must be associated with some departments.
• Supervision: One employee (supervisor) supervises many employees.
Cardinality ratio: 1:N.
Supervisor and supervisee participations: Partial.
• Works_on: An employee can be associated with more than one project and a project can be
associated with many employees.
Cardinality ratio: M:N.
Project and employee participations: Total.
• Dependents_of: One employee may zero or more dependents but a dependent can be
associated with only one employee.
Cardinality ratio: 1:N.
Employee participation: Partial.
Dependent participation: Total.
We are now ready to represents these using ER model. We first familiarize with the symbols of E-R modeling
tool, which are given below.

Entity Example: Employee, Department, City, etc.

Weak Entity Example: Dependent, Project, etc

Attribute Example: Salary, Age, Job name, etc.

Key Attribute Example: SSN, Job Id, Department Number, etc.

Multi-valued Example: SSN, color, Department Number, etc.

Attribute

Relationship Example: Works-for, Lives-in, etc.

Derived Attribute Example: Age, Credit account balance etc.

Composite Attribute Example: Address, Phone Number, etc.

1 N
Entity1 R Entity2 Example: A student has multiple degrees,an employee has multiple phone

numbers,etc.

Total participation of Entity2 in R

Entity1 R Entity2 Example: Participation of Department in Manages

Partial participation of Entity1 and Entity2 in R

Entity1 R Entity2 Example: Employees Participate-in Activities