Data modeling using the Entity

Relationship (ER) Model

Chapter 3

1
 Categories of data models:

• Record-based
– Hierarchical Data Model
– Network Data Model
– Relational Data Model
• Object-based
– The E-R Model
– The Object-Oriented Model
• Physical
– Unifying model.
– Frame memory.
2
 Conceptual modeling is a very important phase in designing a
successful database application.
 The E-R model (which is a popular high-level conceptual data
model) and its variations are frequently used for the conceptual
design of database applications, and many database tools employ
its concepts.
 The diagrammatic notation associated with the E-R model is known
as E-R diagrams.

3
High-level Conceptual Data Models for Database Design

4
High-level Conceptual Data Models for Database Design

 The figure below shows a simplified diagram to illustrate the main

phases of database design.

5
step 1: requirements collection and analysis.
 During this step, the database designers interview prospective
database users to understand and document their requirements.
 These requirements should be specified in ( as detailed and
complete) a form as possible.
 In parallel with specifying data requirements, it is useful to
specify the known functional requirements of the application.
 These consist of user defined operations (transactions) that will
be applied to the database, including both retrieval and updates.

6
Step 2: Conceptual design:
• Once all the requirements have been collected and analyzed, the
next step is to create a conceptual schema (which includes
detailed descriptions of the entity types, relationships, and
constraints) for the database, using a high-level conceptual data
model.
Step 3: logical design
 The next step in database design is the actual implementation of the
database, using a commercial DBMS.
 Most current DBMSs use an implementation data model – such as
the relational or the object_relational data model – so the conceptual
schema is transformed from the high-level data model into
implementation data model.

7
Step 4: physical design :
 The last step is the physical design phase, during which – the
internal storage structures, access paths, and file organizations for
the database files – are specified.
 In parallel with these activities, application programs are designed
and implemented.

8
 E-R Modeling
 The Entity-Relationship model (ER Model) is a graphical designing tool for
implementation of database systems.
 It provides a common, informal and convenient model for communication
between users and the DBA for the purpose of modeling the structure of the data.
 The ER model describes data as entities, relationships, and attributes.
The following components are used in developing E-R model
 Entity
 Attribute
 Keys
 Entity Type & instances
 Entity Set
 Relationship
 Relationship Type & instances
 Relationship Set
 Recursive Relationship
 Degree & Cardinality
9
 Participation
 Entity: An entity is anything that exists and is distinguishable.
example each chair is an entity. Each person, each automobile is an entity.
 An entity may be an object with physical existence (like car, house or an
employee) or it may be an object with a conceptual existence (like a job,
a course, etc…).
 Entities can be classified as regular entity and weak entity.
A. regular entity does not depend on any other entity for its existence.
example, Employee is a regular entity.
A regular entity is represented using a rectangle.
B. weak (or dependent) entity : An entity whose existence depends on the
existence of another entity.
example, the dependent of an employee is a weak entity, whose existence
depends on the entity Employee.
 A dependent entity is represented in a double lined box or a darkened
rectangle.
10
 Attributes, Keys, Entity Types &Entity Sets

What is Attribute
• Each entity has attribute/s, which describes the particular
properties of an entity.
For example, an EMPLOYEE entity may be described by the
employee’s name, age, address, salary, etc…
• The following figure shows two entities and the values of their
attributes.

11
Types of Attributes
• Several types of attributes occur in the ER model:
 Simple V/s Composite
 Single valued V/s Multivalued and
 Stored V/s Derived
(1) Simple (atomic) Vs Composite attributes
 Simple : contains a single value (not divided into sub parts) E.g.
Age, gender
 Composite: Divided into sub parts (composed of other attributes)
E.g. Name, address
(2) Single-valued Vs multi-valued attributes
 Single-valued : have only single value(the value may change but
has only one value at one time) E.g. Name, Sex, Id. No,
colour_of_eyes
 Multi-Valued: have more than one value E.g. Address,
12
dependent-name ,Person may have several college degrees.
(3) Stored vs. Derived Attribute
• Stored : not possible to derive or compute. E.g. Name,
Address
• Derived: The value may be derived (computed) from the
values of other attributes.
• E.g.
 Age (current year – year of birth)
 Length of employment (current date- started date)
 Profit (earning-cost)

13
 Entity Types ,Instances & Entity Sets
 A database usually contains groups of entities that are similar.
 Example: a company may have hundreds of employees and
these employee entities share the same attributes, but each entity
has its own value/s for each attribute.
 An entity type defines a collection (or set) of entities that have
the same attributes.
 Each entity type in the database is described by its name and
attributes.
 Instance: A specific type of entity is called an instance.
Example: (John Smith, 55, 80k) is an instance of the
EMPLOYEE entity type
 The collection of all entities/instances of a particular entity type
in the database at any point in time is called an entity set; Or a
group of similar entities forms an entity set.
14
 Eg: all employees, all persons etc..
• The figure below shows two entity types:
EMPLOYEE and COMPANY and its attributes, and
values for each attributes.

15
 Key Attributes of an Entity Type
 An entity type usually has an attribute whose values are
distinct for each individual entity in the entity set. Such an
attribute is called a key attribute, and its value can be used to
identify each entity uniquely.
 For a PERSON entity, normally the typical key attribute will
be his Ssn (Social Security number).
 For a STUDENT entity, normally the typical key attribute will
be his Student_id.
 In ER diagrams, each key attribute has its name underlined
inside the oval shapes.
 An entity type may have no key, in which case it is called a
weak entity type.

16
Key Attributes of an Entity Type con’td
• If tuples are needed to be unique in the database, we need to make each tuple
distinct. To do this we need to have relational keys that uniquely identify each
record.
• Super Key: an attribute/set of attributes that uniquely identify a tuple within a
relation.
• Candidate Key: a super key such that no proper subset of that collection is a
Super Key within the relation.
• If a super key is having only one attribute, it is automatically a Candidate key.
• If a candidate key consists of more than one attribute it is called Composite
Key.
• Primary Key: the candidate key that is selected to identify tuples uniquely
within the relation.
• Foreign Key: an attribute, or set of attributes, within one relation that matches
the candidate key of some relation.
• A foreign key is a link between different relations to create a view or an
unnamed relation.
17
• The following figure shows an entity CAR with
its attributes.

18
 Relationships
 situation that exists between two database tables when one table
has a foreign key that references the primary key of the other table.
 Whenever an attribute of one entity type refers to another entity
type, some relationship exists.
 In ER model, these references are represented as relationships. For
example, the attribute Manager of the entity DEPARTMENT refers
to an employee who manages the department.
 Also, We may have the relationship that an employee works in a
department.
 A relation can be Strong relationship or Weak relationship.
 A Strong relationship can have attributes and a weak relationship
cannot have any attributes.

19
Relationship Types, Relationship Instances and Relationship Sets

 A relationship type is the schema description of a relationship

which identifies the relationship name and the participating entity
types. Also identifies certain relationship constraints.
 A relationship type R among n entity types E1, E2, E3, …….., En
defines a set of associations – or a relationship set – among entities
from these entity types.
 For example, consider a relationship type WORKS_FOR between
the two entity types EMPLOYEE and DEPARTMENT, which
associates each employee with department for which the employee
works.

20
 Each relationship instance in the relationship set WORKS_FOR
associates one EMPLOYEE entity and one DEPARTMENT entity.
 The following figure depicts the relationship type WORKS_FOR
between EMPLOYEE and DEPARTMENT

21
 In ER diagrams, relationship types are displayed as diamond-shaped
boxes, and the relationship name is displayed inside the box.
 The degree of a relationship type is the number of participating
entity types.
 Hence the above given WORKS_FOR relationship is of degree two.
 A relationship type of degree two is called binary, and one of degree
three is called ternary.
 Generally, higher degree relationships are more complex than
binary relationships.

22
 Role Names and Recursive Relationships
 Each entity type that participates in a relationship type plays a
particular role in the relationship.
 The role name signifies the role that a particular entity from the
entity type plays in each relationship instance.
 For eg: in the WORKS_FOR relationship type, EMPLOYEE plays
the role of employee or worker and DEPARTMENT plays the role
of department or employer.
 Role names are not technically necessary in relationship types
where all the participating entity types are distinct, since each
participating entity type name can be used as the role name.
 However, in some cases the same entity type participates more than
once in a relationship type in different roles.

23
 In such cases, the role name becomes essential for distinguishing the
meaning of each participation.
 Such relationship types are called recursive relationships.
 A relationship between two entities of similar entity type is called
a recursive relationship.
 This means that the relationship is between different instances of
the same entity type.
 The following diagram will show a recursive relationship
SUPERVISION between EMPLOYEE in the supervisor role and
EMPLOYEE in the subordinate role.

24
 A student can be a class monitor and handle other students. Hence, this is a
recursive relationship of entity student with itself.
This is a 1 to many recursive relationship as one student is monitor of
many students.

 An employee can supervise multiple employees. Hence, this is a recursive

relationship of entity employee with itself. This is a 1 to many recursive
relationship as one employee supervises many employees.

25
 The SUPERVISION relationship type relates an employee to a
supervisor, where both employee and supervisor entities are
members of the same EMPLOYEE entity type.
 Hence the EMPLOYEE entity type participates twice in
SUPERVISION: once in the role of supervisor and once in the role
of subordinate.

26
 Constraints on Relationship Types
 Relationship types usually have certain constraints that limit the
possible combinations of entities that may participate in the
corresponding relationship set.
 We can distinguish two main types of relationship constraints:
cardinality and participation.

27
 Cardinality Ratios (for binary relationships)
 The cardinality ratio for a binary relationship specifies the
maximum number of relationship instances that an entity can
participate in.
 eg: in the WORKS_FOR relation ship type, EMPLOYEE :
DEPARTMENT is of cardinality N:1, meaning that any number of
employees can be related to a department.
 The possible cardinality ratios for binary relationships types are
1:1, 1:N, N:1, and M:N
An example of a 1:1 binary relationship is MANAGES, which relates a
DEPARTMENT entity to an EMPLOYEE entity who manages the
department.

28
 The meaning of 1:1 relationship here is that, an employee can
manage one department only and a department can have only one
manager as shown below.

29
 An example of cardinality ratio M:N is shown below with respect
to the relationship type WORKS_ON between an EMPLOYEE
entity type and a PROJECT entity type.
 The meaning of M:N relationship here is that, an employee can
work on several projects and a project can have several employees.

30
 Participation Constraints
 The participation constraint specifies whether the existence of an
entity depends on its being related to another entity via the
relationship type. There are two types of participations;
total and partial.
 If a company policy states that every employee must work for a
department, then an employee entity can exist only if it participates
in at least one WORKS_FOR relationship instance as shown in the
figure below.

31
 Thus, the participation of EMPLOYEE in WORKS_FOR is called total
participation, meaning that every entity in the EMPLOYEE entity type
must be related to a DEPARTMENT entity type via WORKS_FOR.
 Total participation is also called existence dependency.
 The participation of EMPLOYEE in the MANAGES relationship type is
partial participation, because every employee may not be expected to
manage a department.
 It means that some or part of the set of employee entities are related to some
department entity via MANAGES, but not necessary all, as shown below.

32
 Attributes of Relationship Types
 Relationship types can also have attributes, similar to those of entity
types.
 For example, to know the experience of the manager in a company –
it is possible to include an attribute start_date for the MANAGES
relationship type as shown in the figure below.

33
 Weak Entity Type
 Entity types that do not have key attributes of their own are called
weak entity types.
 Entities belonging to a weak entity type are identified by being
related to specific entities from another entity type (called as
owner entity type) in combination with one of their attribute
values.
 The relationship type that relates a weak entity type to its owner is
called identifying relationship of the weak entity type.
 Consider an entity type DEPENDENT, related to an EMPLOYEE
entity, which is used to keep track of dependents of each employee.
 Let the attributes of DEPENDENT be Name (of the dependent),
Birth_date, Sex, and Relationship (to the employee).

34
 Two dependents of two distinct employees may, by chance,
have the same values for Name, Birth_date, Sex, and
Relationship. But still they are distinct entities.
 They are identified as distinct entities only after determining
the particular employee entity to which each dependent is
related.
 A weak entity type normally has a partial key, which is the set
of attributes that can uniquely identify weak entities that are
related to the same owner entity type.
 In the above example, assume that no two dependents of the
same employee ever have the same name.
 So the attribute Name of DEPENDENT can be the partial key.

35
 In the above example, assume that no two dependents of the same
employee ever have the same name.
 So the attribute Name of DEPENDENT can be the partial key.
 In ER diagrams, the partial key attribute is underlines with a dotted
line and both the weak entity and its identifying relationship are
distinguished by double lines as shown below.

36
 ER Diagrams, Naming Conventions, and Design Issues
 In ER diagrams, the emphasis is on representing the schemas rather
than the instances.
 It illustrates the participation of entity types in a relationship type.
 The following are the summary of the notations used in ER
diagrams

37
38
 Proper Naming of Schema Constructs
 When designing a database schema, one should choose a
meaningful name for entity types, attributes, relationship types,
 Normally choose singular names for entity types.
 the entity type and relationship types names are represented
with upper case letters,
 attribute names are initial letter capitalized, and role names are
lower case letters.
 Another naming consideration involves choosing binary
relationship names to make the ER diagram of the schema
readable from left to right and top to bottom

39
 Design Choices for ER conceptual Design

 It is occasionally difficult to decide whether a particular concept in

the miniworld should be modeled as entity type, an attribute, or a
relationship type.
 In general, the schema design process should be considered as an
iterative refinement process,
 an initial design is created and then iteratively refined until the most
suitable design is reached.
 Some of the refinements that are often used include the following.

40
 A concept may be first modeled as an attribute and then refined into
a relationship because, it is determined that the attribute is a
reference to another entity type..
 Similarly, an attribute that exists in several entity types may be
elevated or promoted to an independent entity type.
 For eg: suppose that several entity types in a UNIVERSITY
database, such as STUDENT, INSTRUCTOR, and COURSE, and
each has an attribute Department in the initial design. The designer
may then choose to create an entity type DEPARTMENT with a
single attribute Dept_name and relate to the three entity types
(STUDENT, INSTRUCTOR and COURSE) via appropriate
relationships.

41
 As inverse refinement to the above mentioned case may also be
applied. For eg: if an entity type DEPARTMENT exists in the initial
design with a single attribute Dept_name and is related to only one
other entity type, say STUDENT. In this case, DEPARTMENT may
be reduced or demoted to an attribute of STUDENT entity.
 There can be some refinement on the choices concerning the degree
of a relationship, concerning the specialization/generalization, also
top-down and bottom-up refinements that are common in large-
scale conceptual schema design.

42
 An Example Database Application
 An example database application, called COMPANY will be
described, which serves to illustrate the basic ER model concepts
and their use in schema design.
 The company database keeps track of a company’s employees,
departments, and projects.
 Suppose that after the requirements collection and analysis phase,
the database designers provide the following description of the
miniworld – the part of the company to be represented in the
database.

43
 The company is organized into departments. Each department has a unique
name, a unique number, and a particular employee who manages the
department. Also it is being tracked that the starting date of that employee when
he began managing the department. A department may have several locations as
well.
 A department controls a number of projects, each of which has a unique name,
a unique number and a single location.
 Stores each employee’s name, social security number, address, salary, sex, and
birth date.
 An employee is assigned to one department, but may work on several projects,
which are not necessarily controlled by the same department. It keeps track of
the number of hours per week that an employee works on each project. Also it
keeps track of the direct supervisor of each employee.
 The database keeps track of the dependents of each employee for insurance
purposes. It keeps each dependent’s first name, sex, birth date, and relationship
to the employee.

44
 The step-by-step process of deriving this schema from the stated
requirements will be described with ER model concepts and will be
represented in ER diagram
 According to the requirements described, 4 entity types can be
identified as follows:

45
1) An entity type DEPARTMENT with attributes Name, Number,
Locations, Manager, and Manager_start_date. Location is the
only multivalued attribute. Both Name and Number can be key
attribute, since each was specified to be unique.
2) An entity type PROJECT with attributes Name, Number,
Locations, and Controlling_department. Both Name and
Number can be key attributes.
3) An entity type EMPLOYEE with attributes Name, Ssn, Sex,
Address, Salary, Birth_date, Department, and Supervisor. Both
Address and Name may be composite attributes; (even it is not
specified in the requirements).
4) An entity type DEPENDENT with attributes Employee,
Depedent_name, Sex, Birth_date, and Relationship (to the
employee).

46
• All the above four entity types and its attributes are
shown separately using ER diagrams as given below.

Some of the attributes shown in the above ER diagram will be refined to relationships.
47
 Refining the ER Diagram
 It is possible to refine the database design by changing the
attribute that represents relationship into relationship types.
 If some cardinality ratio or dependency cannot be determined
from the requirements, the users must be questioned further to
determine these structural constraints.

48
In the above COMPANY database example, the following relationship types are specified
• MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT.
EMPLOYEE participation is partial. DEPARTMENT participation is not clear from the
requirements. When the users are questioned, it became clear that a department must have a
manager at all times, which implies a total participation. The attribute Start_date is assigned
to this relationship type.
• WORKS_FOR, a 1:N relationship type between DEPARTMENT and EMPLOYEE. Both
participation are clearly a total one.
• CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT. The
participation of the PROJECT is total, whereas that of DEPARTMENT is determined to be
partial, after consultation with the users indicates that some departments may control no
projects.
• SUPERVISION, a 1:N relationship type between EMPLOYEE (in the supervisor role) and
EMPLOYEE (in the supervisee role). Both participations are determined to be partial, after
the users indicate that not every employee is a supervisor and not every employee has a
supervisor.
• WORKS_ON, determined to be an M:N relationship type between EMPLOYEE and
PROJECT with an attribute Hours. After the users indicate that a project can have several
employees working on it, both participations are total.
• DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and DEPENDENT,
which is also the identifying relationship for the weak entity type DEPENDENT. The
participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.
49
• After specifying the above six relationship types, remove the
attributes from the entity type that have been refined into
relationships.
• These include Manager and Manager_start_date from
DEPARTMENT; Controlling_department from PROJECT;
Department, Supervisor, and Work_on from EMPLOYEE; and
Employee from DEPENDENT.

50
• At this moment, it is possible to draw an ER schema
diagram for the COMPANY database with all its entity
types and relationship types, and is shown below.

51
Alternative Notations for ER diagrams

52
 There are many alternative diagrammatic notations for displaying
ER diagrams. Universal Modeling Language (UML) notation for
class diagram has been proposed as a standard for conceptual object
modeling.
 One alternate ER notation involves associating a pair of integer
numbers (min, max) with each participation of an entity type E in a
relationship type R, where 0 ≤ min≤ max ≥ 1.
 The numbers mean that for each entity e in E, e must participate in
at least min and a most max relationship instances in R at any point
in time.
 The (min, max) notation is more precise, and can be used to specify
structural constraints for relationship types of any degree.

53
54
 Converting ER Diagram to Relational Tables
• Three basic rules to convert ER into tables or relations:
Rule 1: Entity Names will be automatically be table names
Rule 2: Mapping of attributes: attributes will be columns of the respective
tables.
 Atomic or single-valued or derived or stored attributes will be columns
 Composite attributes: the parent attribute will be ignored and the
decomposed attributes (child attributes) will be columns of the table.
 Multi-valued attributes: will be mapped to a new table where the
primary key of the main table will be posted for cross referencing.
Rule 3: Mapping of relationships: relationship will be mapped by using a
foreign key attribute. Foreign key is a primary or candidate key of one
relation used to create association between tables

55
A. For a relationship with One-to-One Cardinality:
 Post the primary key or candidate key of one of the table into the other as a
foreign key.
 In cases where one entity is having partial participation on the relationship, it
is recommended to post the candidate key of the partial participants to the total
participant so as to save some memory location due to null values on the
foreign key (FK)attribute.
 example:
 for a relationship between Employee and Department where employee
manages a department, the cardinality is one-to-one as one employee
will manage only one department and one department will have one
manager.
 Here the Primary Key (PK)of the Employee can be posted to the
Department or the PK of the Department can be posted to the Employee.
 But the Employee is having partial participation on the relationship
"Manages" as not all employees are managers of departments.
 Thus, even though both ways is possible, it is recommended to post the
primary key of the EMPLOYEE to the DEPARTMENT table as a
foreign key. 56
B. For a relationship with One-to-Many Cardinality:
 Post the primary key or candidate key from the ―one‖ side as a
foreign key attribute to the ―many‖ side.
 Example: For a relationship called ―Belongs To‖ between
Employee (Many) and Department (One) the primary or candidate
key of the one side, which is Department, should be posted to the
many side, which is Employee table.
C. For a relationship with Many-to-Many Cardinality:
 For relationships having many to many cardinality, one has to
create a new table and post primary key or candidate key from the
participant entities as foreign key attributes in the new table along
with some additional attributes (if applicable).
 The same approach should be used for relationships with degree
greater than binary
 Example: relationship between student and course
57
• A student have many courses also, a course have many students
• Student table may look the following table.
Stud_id Stud_name Ccourse_code
123 abebe Cosc3030,3031,3019
124 kebede Cosc3030,3031,3019

 Hence from the above table one column stores multiple values, this is difficult to
maintenance and query. For this we need join table.
 Jpoin table is atable that sites between 2 other tables of many to many relationships. So
create new table course_enrollemnt
Stud_id Stud_name Ccourse_code
Course_enrollment table =join table
123 abebe Cosc3030
123 abebe Cosc3031

Student table Course table

Stud_id Stud_name course_name Ccourse_code
123 abebe DBMS Cosc3030
123 abebe OOP with Java Cosc3031
58
 Example

To illustrate the major rules in mapping ER to relational schema:

59
 Example: Converting the following ER Diagram to
Relational Tables
 To illustrate the major rules in mapping ER to
relational schema:
• After we have drawn the ER diagram, the next thing is to
map the ER into relational schema so as the rules of the
relational data model can be tested for each relational
schema.
• The mapping can be done for the entities followed by
relationships based on the rule of mapping.
• The mapping has been done as follows.

60
61
Mapping EMPLOYEE Entity:
• There will be Employee table with Fname,Minit,Lname,Ssn,
Bdate, Address,sex and Salary being the columns.
• The composite attribute Name will be ignored as its decomposed
attributes (Fname,Minit and LName) are columns in the Employee
Table.
• The Telephone attribute will be a new table as it is multi-valued.

62
Mapping DEPARTMENT Entity:
• There will be Department table with ,Dname
and Dnumber and Dlocation is multi valued

63
Mapping PROJECT Entity:
• There will be Project table with Pnumber,
PName, and dnum being the columns.

64
Mapping Dependent Entity:

65
Final Converted relational table

66
• After converting the ER diagram in to table
forms, the next phase is implementing the
process of normalization.

67
 excercise
• Example 1: Build an ER Diagram for the following information: A
student record management system will have the following two
basic data object categories with their own features or properties:
Students will have an Id, Name, Dept, Age, GPA and Course will
have an Id, Name, Credit Hours. Whenever a student enrolls in a
course in a specific Academic Year and Semester, the Student will
have a grade for the course
• Then, create the relational database schema for the above database.

68
ER diagram

69