1

Data Modeling Using the Entity-Relationship Model

2

Contents

1. Introduction

2. Database Design Process

3. An example of Database Application

4. Entity Types, Entity Sets, Attributes and Keys

5. Relationships, Relationship Types, Roles and Structural

Constraints

6. Weak Entity Types

7. ER Diagrams, Naming Conventions and Design Issues

Ref: Chapter 3, Navathe

3

1. Introduction

• Conceptual modeling is an important phase in designing a

successful database application.

• Database application: which refers to particular database, e.g.

BANK.

4

2. Database Design Process

5

• Requirement collection and analysis:

– interviewing prospective database users to understand and document their

data requirements.

– Specifying known functional requirements (user defined operation that will

be applied to the database and they include both retrievals and update) of

the application.

• Conceptual design:

– Creating conceptual schema for the database using high level conceptual

data model.

– Conceptual schema is a concise description of data requirements of the

user and includes detailed descriptions of the entity type, relationships and

constraints.

– Reference to ensures all users’ data requirements are meet and that the

requirements do not include conflicts.

– This enables database designers to concentrate on specifying the

properties of the data rather than storage details.

6

• Logical Design or Data modeling:

– Actual implementation of database design using commercial DBMS.

– Uses relational or object database model.

– Result is a database schema in the implementation data model of the

DBMS.

• Physical Design:

– Specify internal storage structures, access paths and file organization for

the database files.

– Application programs are designed and implemented as database

transaction corresponding to the high-level transaction specifications.

7

3. An example of Database Application

• Database Application: Company

• Requirements: Keeps track of a company’s employees,

department, and projects

• Departments

– Unique name & number

– A particular employee manages a department

– Start date when the manager began managing

– Department may have several locations

• Projects

– Unique name & number

– Single location

– Controlled by a department

8

• Employees

– Name

– SSN (IRD)

– Address

– Salary, sex & birth date

– Assigned to one department, but may work on several projects

– Track number of hours per week that an employee works on each project

– Track the direct supervisor of each employee

• Dependents

– First name

– Sex & birth date

– Relationship to employee

9

10

4. Entity Types, Entity Sets, Attributes and Keys

• Entities and Attributes

• Entity Types, Entity Sets, Keys and Value Sets

• Initial conceptual design of the Company database

• Entity:

– which is a “thing” in the real world with an independent existence

– It may be an object with a physical existence, e.g. person, car, house or

employee.

– It may be an object with a conceptual existence, e.g. a company, a job, or

an university course.

• Attribute:

– The particular properties that describe entity, e.g. employee entity may be

described by name, age, address, salary and job.

– Attribute value

11

• Types of Attributes:

– Composite / Simple (Atomic): Address

– Single-valued/ Multivalued: age / college degrees

– Stored/ Derieved: Birth date / age

– Null: e.g. apartment number, Null can also be used if we do not know the value of

an attribute for a particular entity (e.g. Home phone)

– Complex Attributes: Nesting composite and multivalued attribute in an arbitrary

way. E.g. Attribute AddressPhone for PERSON entity

{AddressPhone({Phone(AreaCode, PhoneNumber)},

Address(StreetAddress(Number, Street, ApartmentNumber), City, State, Zip))}

• Entity Types:

– Collection or set of entities that have the same attributes.

– Represented in ER diagram as a rectangular box enclosing the entity type name.

– Attributes are enclosed in ovals, multivalued attribute are displayed in double

ovals.

– It describes the schema or intension for a set of entities that share the same

structure.

12

• Entity Set:

– The collection of all entities of a particular type in the database at any point in

the time.

– E.g. The set of all persons having an account at a bank is the entity set

CUSTOMER. Set of all accounts in a particular bank is the entity set ACCOUNT.

• Key Attributes of an Entity Type:

– Uniqueness constraint on attributes

– Attribute whose values are distinct for each individual entity in the collection.

– Composite attribute as a key attribute.

– In ER diagram key attribute are underlined.

– Weak entity type: entity type with no key.

• Value Sets (Domain) of attribute:

– Set of values that may be assigned to attribute. E.g. Age (20-70),

name(alphabetic and space)

13

Initial conceptual design of the Company database

14

Problem

• Composite and multivalued attributes can be nested to any number of levels. Suppose we want to design an attribute for a STUDENT entity type to keep track of previous college education. Such an attribute will have one entry for each college previously attended and each such entry will be composed of college name, start and end dates, degree entries, and transcript entries. Each degree entry contains the degree name and the month and year the degree awarded, and each transcript entry contains a course name, semester, year, and grade. Design attribute to hold this information.

15

Relationships, Relationship Types, Roles and Structural Constraints

• Introduction

• Relationship Types, Sets and Instances

• Relationship Degree, Role Names and Recursive Relationships

• Constraints on Relationship Types

• Attributes of Relationship Types

16

• Introduction

– Attribute of one entity type refers to another entity type.

– The attribute Manager of DEPARTMENT refers to an employee who

manages the department Department.

– The attribute ControllingDepartment of PROJECT refers to the

department that controls the project.

– The attribute Supervisour of EMPLOYEE refers to another employee.

– The attribute Department of EMPLOYEE refers to the department for

which the employee works.

– In the ER model, references (between entity types) should be

represented as relationships, not attributes.

– A relationship is an association among several entities.

– Relationship will be shown as diamond-shaped boxes in the ER

diagram

17

Relationship Types, Sets and Instances

• A relationship type R among n entity types E1, E2, . . ., En

defines a set of associations or a relationship set among

entities from these types.

• As for entity types and entity sets, relationship type and its

corresponding relationship set are customarily referred to by

the same name R.

• Each of the entity types E1, E2, . . .,En is said to participate in

the relationship type R.

• Relationship set is a set of relationships of the same type.

18

ri – relationship instances

CUSTOMER : ACCOUNT ; CustAcct

19

Relationship Degree, Role Names and Recursive Relationships

• Degree of Relationship Type: number of participating entity

type

• WORKS_FOR relationship is of degree 2.

• Relationship type of degree 2 is called binary and degree 3 is

called ternary.

20

• Relationships as Attributes:

– WORKS_FOR relationship type represents attributes

Department of EMLOYEE or Employees of DEPARTMENT.

Role Names and Recursive Relationships:

– Each entity type that participates in a relationship type

plays a particular role in the relationship.

– Role Name

• Signifies the role of the participating entity

• Helps to explain what the relationship means

• Not necessary where participating entity types are distinct

(WORKS_FOR)

– Recursive Relationships: Participation of the same entity

types more than once in a relationship type.

21

1 – Supervisor2 - Supervisee

22

• Constraints on Relationship Types:

– Cardinality Ratio: Cardinality specifies the number of

relationship instances that an entity can participate in

• 1:N (DEPARTMENT : EMPLOYEE ; WORKS_FOR)

• 1:1 (EMPLOYEE : DEPARTMENT; MANAGES)

• M:N (EMPLOYEE : PROJECT ; WORKS_ON)

23

• Participation Constraints and Existence Dependencies:

– Specifies whether the existence of an entity depends on its

being related to another entity via the relationship type

– Types

• Total (Existence dependency)

– If every employee must work for a department, then an

employee entity can exist only if it participates in a

WORKS_FOR relationship.

– Every entity in “the total set” of employee entities must be

related to a department entity by the WORKS_FOR

relationship.

– Total participation is also called existence dependency.

24

• Partial

– Every employee is not expected to manage a department.

– A “part of the set” of employees are related to a

department by the MANAGES relationship.

• Total participation is shown as a double line

• Partial participation is shown as a single line

• Attributes of Relationship Types

– Relationship types can have attributes

– Consider the number of hours per week that an employee

works on a particular project

– Hours attribute on WORKS_ON relationship

25

• Weak Entity Types:

– Entity types that do not have key attributes of their own

– Entities belonging to a weak entity type are identified by being

related to specific entities from another entity type (identifying or

owner entity type) in combination with some of the attribute

values.

– Has a total participation constraint with respect to its owning entity

type

– Consider the DEPENDENT entity type (two distinct employees may

have the same value for attribute for DEPENDENT)

– Partial key

• A set of attributes that can uniquely identify the weak entities that are

related to the same owner entity (no two dependents of the same

employee ever have the same first name, “Name”-Partial key)

– Boxes and diamonds are double lines

26

Refining the ER Design for the COMPANY

Database

• MANAGES

– 1:1 between EMPLOYEE & DEPARTMENT

– EMPLOYEE participation is partial

– DEPARTMENT participation is unclear

– StartDate attribute

• WORKS_FOR

– 1:N between DEPARTMENT & EMPLOYEE

– Both participations are total

• CONTROLS

– 1:N between DEPARTMENT & PROJECT

– PROJECT participation is total

– DEPARTMENT participation is partial

27

• SUPERVISION

– 1:N between EMPLOYEE (in supervisor role) & EMPLOYEE (in

supervisee role)

– Both participations determined to be partial after users indicate

not every employee has a supervisor.

• WORKS_ON

– M:N between EMPLOYEE & PROJECT

– Both participations are total

– Hours attribute

• DEPENDENTS_OF

– 1:N between EMPLOYEE & DEPENDENT

– EMPLOYEE participation is partial

– DEPENDENT participation is total

28

• ER Diagram Notation

29

30