Data Modelling using Entities – Relationship(ER) Model

 Conceptual modeling is a very important phase in designing a

successful database application
Chapter Outline

 Using High-Level Conceptual Data Models for Database Design

 Entity Types, Entity Sets, Attributes, and Keys
 A Sample Database Application
 Relationship Types, Relationship Sets, Roles, and Structural
Constraints
 Weak Entity Types
 ER Diagrams
Using High-Level Conceptual Data Models for Database Design
Entity Types, Entity Sets, Attributes, and Keys
 Entity
 a thing in the real world with an independent existence.
 may be an object with a physical existence

- for example, a particular person, car, house, or employee or

 may be an object with a conceptual existence

- for instance, a company, a job, or a university course

 Attributes

 Particular properties that describe entity

 For example, an EMPLOYEE entity may be described by the

employee’s name, age, address, salary, and job

Figure : Two entities, EMPLOYEE e1, and COMPANY c1, and their
attributes
 Types of attributes:
 Composite versus Simple (Atomic) Attributes

 Single-valued versus multivalued

 Stored versus derived

 NULL values

 Complex attributes
Composite versus Simple (Atomic) Attributes

 Composite Attributes
• can be divided into smaller subparts, which represent more
basic attributes with independent meanings.
• For example, the Address attribute of the EMPLOYEE entity
can be subdivided into Street_address, City, State, and Zip
• can form a hierarchy
• For example, Street_address can be further subdivided into
three simple component attributes: Number, Street, and
Apartment_number
 Figure: A hierarchy of composite attributes.

• The value of a composite attribute is the concatenation of the

values of its component simple attributes.
 Simple or Atomic attributes
• Attributes that are not divisible
• Example: SSN
Single-Valued versus Multivalued Attributes

 Single-Valued
• attributes that have a single value for a particular entity
• For example: age attribute of a person
 Multivalued
• attributes that can have a set of values
• For example: college degree of a person
Stored versus Derived Attributes
 Stored
• An attribute, which cannot be derived from other attribute
• For example, BirthDate of an employee
 Derived
• Attributes derived from other stored attribute
• For example age from Date of Birth and Today’s date

Null Value Attribute(Optional Attribute)

• attribute may not have a value in it and can be left blank
• For example, the Apartment_number attribute of an address
applies only to addresses that are in apartment buildings and
not to other types of residences,such as single-family homes.
 Complex Attributes
• If an attribute for an entity, is built using composite and multivalued
attributes, then these attributes are called complex attributes
• For example, a person can have more than one residence and each
residence can have multiple phones, an addressphone for a person
entity can be specified as –

{ Addressphone (phone {(Area Code, Phone Number)},

Address(Sector Address (Sector Number,House Number),

City, State, Pin))

Here {} are used to enclose multivalued attributes and () are

used to enclose composite attributes with comma separating

individual attributes
 Entity Types
 a collection (or set) of entities that have the same attributes
 Each entity type in the database is described by its name and
attributes

 Entity set
 collection of all entities of a particular entity type in the
database at any point in time
 the entity set is usually referred to using the same name as
the entity type
 Figure: Two entity types, EMPLOYEE and COMPANY, and some
member entities of each.
 An entity type describes the schema or intension for a set of
entities that share the same structure.
 The collection of entities of a particular entity type is
grouped into an entity set, which is also called the extension of
the entity type.
 An entity type is represented in ER diagrams a rectangular box
enclosing the entity type name
 Attribute names are enclosed in ovals and are attached to their
entity type by straight lines
 Composite attributes are attached to their component
attributes by straight lines.
 Multivalued attributes are displayed in double ovals
Key Attributes of an Entity Type
 An entity type usually has one or more attributes whose values
are distinct for each individual entity in the entity set. Such an
attribute is called a key attribute, and its values can be used to
identify each entity uniquely
 For example, the Name attribute is a key of the COMPANY
entity because no two companies are allowed to have the
same name.
 In ER diagrammatic notation, each key attribute has its name
underlined inside the oval
 Some entity types have more than one key attribute.
 For example, each of the Vehicle_id and Registration attributes
of the entity type CAR is a key in its own right
 Example:
The CAR entity type with two key attributes, Registration and
Vehicle_id.

Figure : ER diagram notation.

 Value Sets (Domains) of Attributes
 set of values that may be assigned to that attribute for each

individual entity
 For ex: if the range of ages allowed for employees is between

18 and 70, we can specify the value set of the Age attribute of

EMPLOYEE to be the set of integer numbers between 18 and 70

 Value sets are not displayed in ER diagrams, and are
specified using the basic data types available in most
programming languages, such as integer, string, Boolean,
A Sample Database Application

Miniworld : COMPANY database keeps track of a company’s

employees, departments, and projects.
 After the requirements collection and analysis phase, the
database designers provide the following description of the
miniworld:
 The company is organized into departments.
 Each department has a unique name, a unique number, and a
particular employee who manages the department. We keep
track of the start date when that employee began managing
the department. A department may have several locations.
 A department controls a number of projects, each of which
has a unique name, a unique number, and a single location.
 We store each employee’s name, Social Security number,
address, salary, gender, 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.
 We keep track of the current number of hours per week that an
employee works on each project. We also keep track of the
direct supervisor of each employee (who is another employee).
 We want to keep track of the dependents of each employee for
insurance purposes. We keep each dependent’s first name,
gender, birth date, and relationship to the employee.
Relationship Types, Relationship Sets, Roles, and Structural
Constraints

Relationship
 An association among two or more entities
 Each relationship has a name

ex: Teacher teaches Student

 For example
- The attribute Manager of DEPARTMENT refers to an
employee who manages the department
- The attribute Controlling_department of PROJECT refers to the
department that controls the project
 In the ER model, these references should not be represented
 A relationship type R among n entity types E1, E2, ..., En
defines a set of associations

 Each of the entity types E1, E2, ..., En is said to participate in the
relationship type R

 similarly, each of the individual entities e1, e2, ..., en is said to

participate in the relationship instance ri = (e1, e2, ..., en )

 Informally, each relationship instance ri in R is an association of

entities, where the association includes exactly one entity from
each participating entity type.
 Example: consider a relationship type WORKS_FOR between
the two entity types EMPLOYEE and DEPARTMENT, which
associates each employee with the department for which the
employee works in the corresponding entity set.
 Each relationship instance in the relationship set WORKS_FOR
associates one EMPLOYEE entity and one DEPARTMENT entity.
Figure : Some instances in the WORKS_FOR relationship set, which
represents a relationship type WORKS_FOR between EMPLOYEE and
DEPARTMENT.
 employees e1 , e3, and e6 work for department d1

 employees e2 and e4 work for department d2 and

 employees e5 and e7 work for department d3

 In ER diagrams, relationship types are displayed as diamond-

shaped boxes, which are connected by straight lines to the
rectangular boxes representing the participating entity types.
 The relationship name is displayed in the diamond-shaped box
Relationship Degree, Role Names, and Recursive
Relationships

 Degree of a Relationship Type

 Denotes the number of participating entity types.
 can be

1. Unary

ex:
- Binary

- Ternary
Role Names and Recursive Relationships

 The role name signifies the role that a participating entity from
the entity type plays in each relationship instance, and helps to
explain what the relationship means.
 For example, 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.
 In such cases the role name becomes essential for distinguishing
the meaning of the role that each participating entity plays. Such
relationship types are called recursive relationships.
 Example of recursive relationships : SUPERVISION relationship
type
 The SUPERVISION relationship type relates an employee to a

supervisor, where both employee and supervisor entities are

members of the same EMPLOYEE entity set
 Hence, the EMPLOYEE entity type participates twice in
SUPERVISION: once in the role of supervisor (or boss), and once
in the role of supervisee (or subordinate)

 Each relationship instance ri in SUPERVISION associates two

employee entities ej and ek , one of which plays the role of

supervisor and the other the role of supervisee.
Figure : A recursive relationship SUPERVISION between
EMPLOYEE in the supervisor role (1) and EMPLOYEE in the
subordinate role (2).
Constraints on Binary Relationship Types

 Relationship types usually have certain constraints that limit the

possible combinations of entities that may participate in the
corresponding relationship set.
 These constraints are determined from the miniworld situation
that the relationships represent.
 Two main types of binary relationship constraints:
 cardinality ratio and
 participation.
Cardinality Ratios for Binary Relationships:
 specifies the maximum number of relationship instances that
an entity can participate in
 For example, in the WORKS_FOR binary relationship type,
DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N, meaning
that each department can be related to any number of
employees, but an employee can be related to (work for) only
one department
 The possible cardinality ratios for binary relationship types are
1:1, 1:N, N:1, and M:N.
Example of a 1:1 binary relationship
 MANAGES which relates a department entity to the employee
who manages that department
 This represents the miniworld constraints that—at any point in
time—an employee can manage one department only and a
department can have one manager only
Example of a M:N binary relationship

 The relationship type WORKS_ON is of cardinality ratio M:N,

because the mini-world rule is that an employee can work on
several projects and a project can have several employees.
 Cardinality ratios for binary relationships are represented on ER

diagrams by displaying 1, M, and N on the diamonds

Participation Constraints and Existence Dependencies.

 This constraint specifies the minimum number of relationship

instances that each entity can participate in, and is sometimes

called the minimum cardinality constraint

 There are two types of participation constraints:
• Total
• Partial
Total participation

 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
 Thus, the participation of EMPLOYEE in WORKS_FOR is called
total participation, meaning that every entity in the total set of
employee entities must be related to a department entity via
WORKS_FOR
 Total participation is also called existence dependency
Partial participation

 we do not expect every employee to manage a department

 so the participation of EMPLOYEE in the MANAGES relationship
type is partial, meaning that some or part of the set of
employee entities are related to some department entity via
MANAGES, but not necessarily all.
 In ER diagrams, total participation is displayed as a double line
connecting the participating entity type to the relationship,
whereas partial participation is represented by a single line
 cardinality ratio + participation constraints
=
structural constraints of a relationship type.
Attributes of Relationship Types

 Relationship types can also have attributes, similar to those

of entity types.
 For example, to record the number of hours per week that an
employee works on a particular project, we can include an
attribute Hours for the WORKS_ON relationship type
 Another example is to include the date on which a manager

started managing a department via an attribute Start_date

for the MANAGES relationship type

 Attributes of 1:1 relationship types can be migrated to one of
the participating entity types
 For a 1:N relationship type, a relationship attribute can be

migrated only to the entity type on the N-side of the

relationship.

 For M:N relationship types, some attributes may be

determined by the combination of participating entities in a

relationship instance, not by any single entity. Such attributes

must be specified as relationship attributes.

.
Weak Entity Types

 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 in
combination with one of their attribute values
 We call this other entity type the identifying or owner entity
type
 we call the relationship type that relates a weak entity type to
its owner the identifying relationship of the weak entity type
 Consider the entity type DEPENDENT, related to EMPLOYEE,
which is used to keep track of the dependents of each
employee via a 1:N relationship
 In our example, the attributes of DEPENDENT are
Name,Birth_date, gender, and Relationship (to the employee).
 Two dependents of two distinct employees may, by chance,
have the same values for Name, Birth_date, gender, and
Relationship, but they are still distinct entities.
 They are identified as distinct entities only after determining the
particular employee entity to which each dependent is related.
 Each employee entity is said to own the dependent entities that
are related to it.
 A weak entity type always has a total participation constraint
(existence dependency) with respect to its identifying relationship
because a weak entity cannot be identified without an owner entity.
 A weak entity type normally has a partial key, which is the attribute
that can uniquely identify weak entities that are related to the same
owner entity.
 In our example, if we assume that no two dependents of the same
employee ever have the same first name, the attribute Name of
DEPENDENT is the partial key.
 In ER diagrams, both a weak entity type and its identifying
relationship are distinguished by surrounding their boxes and
diamonds with double lines.
 The partial key attribute is underlined with a dashed or dotted line.
Topic for Self Learning

ER Diagrams, Naming Conventions, and Design Issues

 Summary of Notation for ER Diagrams

 Proper Naming of Schema Constructs
 Design Choices for ER Conceptual Design
 Alternative Notations for ER Diagrams
Example: A UNIVERSITY Database
Question Bank
1. Explain with a neat diagram, the phases of database design.
2. Explain the following terms with an example for each:
i) Entity ii) attribute iii) entity type iv)entity set
v) key attribute vi) value set v)degree of a relationship type
vi) role names vii) cardinality ratio
viii) participation constraints
3. Explain the different types of attributes that occur in an ER
model with an example.
4. Explain recursive relationship type with an example.
5. What is a weak entity type? Explain the role of partial key in the
design of weak entity type.
6. List and explain symbols used in ER diagram and their meaning.
7. Discuss the naming conventions used for ER schema
diagrams.

8. Design an ER diagram for an insurance company. Assume

suitable entity types like CUSTOMER, AGENT, BRANCH,
POLICY, PAYEMENT and the relationship between them.
9. Design an ER - diagram for the Movie - database considering the
following requirements:

i) Each Movie is identifies by its title and year of release, it has length

in minutes and can have zero of more quotes, language.

ii) Production companies are identified by Name, they have address,

and each production company can produce one or more movies.

iii) Actors are identified by Name and Date of Birth, they can act in

one or more movies and each actor has a role in a movie.

iv) Directors are identified by Name and Date of Birth, so each

Director can direct one or more movie and each movie can be

directed by one or more Directors.

v) Each movie belongs to anyone category like Horror, action, Drama,

etc.
10. Draw a ER-Diagram of movie database. Assume your own
entities(minimum 4) attributes and relationships.
11. Draw an ER diagram for BANK database schema with atleast
five entity types. Also specify primary key and structural
constraints
College database

 Each college contains many departments

 Each department can offer any number of courses.
 For each departments there is a head
 Many instructors can work in a department
 An instructors can work only in one department
 An instructor can take any number of courses
 A student can enroll for any number of courses