Database Systems

Data Modeling Using the Entity-Relationship (ER)

Model
Overview of Database Design Process

• Two main activities:

• Database design
• Applications design
• Focus in this chapter on conceptual database
design
• To design the conceptual schema for a database
application
• Applications design focuses on the programs and
interfaces that access the database
• Generally considered part of software engineering
Entity–relationship (ER) model
• Is a popular high-level conceptual data model.
• Frequently used for the conceptual design of
database applications
ER concepts
• The ER model describes data as entities,
relationships, and attributes
• Entities and Their Attributes:
• Entity: which is a thing or object in the real world with
an independent existence.
• Can be an object with a physical existence: i.e. a
particular person, car, house, or employee)
• Can be an object with a conceptual existence: i.e. a
company, a job, or a university course)
ER concepts

• Attributes: Characteristics or Properties of Entity

• i.e. Employee’s First name, Last name, address etc.
• Simple Attributes: are atomic
• Composite attributes: divided into smaller subparts
• form a hierarchy
• i.e. the Address attribute of the
EMPLOYEE(Street_address, City, State, and Zip)
• First name and last name of employee.
ER concepts
• Single-Valued Attributes: have a single value for a
particular entity.
• i.e. Age is a single-valued attribute of a person.
• Multivalued Attributes: have a set of values for the
same entity.
• i.e. Car can have more than two colors
• i.e. Person can have one or more degrees in college
• Have lower and upper bounds to constrain the number
of values allowed for each individual entity. i.e. car can
have two colors at most.
• Denoted as {Color} or {PreviousDegrees}.
ER concepts
• Derived Attributes: two (or more) attribute values
are related.
• i.e. Age can be derived from birthdate
• So, age is a derived attribute.
• Stored Attribute: that are already specified but not
derived
• Complex Attributes:
• i.e. a person can have more than one residence and
each residence can have a single address and multiple
phones
ER Concepts
• Key Attributes of an Entity Type: distinct for each
individual entity in the entity set. and its values can be
used to identify each entity uniquely also called primary
key(PK)
• For example, the Name attribute is a key of the
COMPANY entity type because no two companies are
allowed to have the same name.
• A key attribute may be composite.
• i.e., Registration is a key of the CAR entity type with
components (Number, State).
• An entity type may also have no key, in which case it is
called a weak entity type.
Displaying an Entity type
• In ER diagrams, an entity type is displayed in a
rectangular box
• Attributes are displayed in ovals
• Each attribute is connected to its entity type
• Components of a composite attribute are connected to
the oval representing the composite attribute
• Each key attribute is underlined
• Multivalued attributes displayed in double ovals
NOTATION
for ER
diagrams
A Sample Database Application
• The COMPANY database keeps track of a company’s
employees, departments, and projects.
• 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 Sample Database Application
• A department controls a number of projects, each of which
has a unique name, a unique number, and a single location.
• The database will store each employee’s name, a unique
Social Security number, address, salary, sex (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. It is required to keep track of the
current number of hours per week that an employee works
on each project, as well as the direct supervisor of each
employee (who is another employee).
• The database will keep track of the dependents of each
employee for insurance purposes, including each
dependent’s first name, sex, birth date, and relationship to
the employee.
Initial Conceptual Design of Entity Types
for the COMPANY Database Schema
•Based on the requirements, we can identify
four initial entity types in the COMPANY
database:
• DEPARTMENT
• PROJECT
• EMPLOYEE
• DEPENDENT
•The initial attributes shown are derived from
the requirements description
Slide 3- 16
Initial Conceptual Design of the
COMPANY Database
• Four entity types:
1. Entity type: DEPARTMENT
• Attributes: Name, Number, Locations, Manager, and
Manager_start_date.
• Locations is the only multivalued attribute.
• key attributes: Name and Number because each was
specified to be unique.
2. Entity type: PROJECT
Attributes: Name, Number, Location, and
Controlling_department.
Key Attributes: Both Name and Number
are (separate) key attributes.
Initial Conceptual Design of the
COMPANY Database
• Entity type: EMPLOYEE
• Attributes: Name, Ssn, Sex, Address, Salary, Birth_date,
Department, and Supervisor
• Composite Attributes: Name and Address may be
composite attributes; however, this was not specified in
the requirements.
Initial Conceptual Design of the
COMPANY Database
• Entity type: DEPENDENT
• Attributes: Employee, Dependent_name, Sex,
Birth_date, and Relationship (to the employee).
• Multivalued composite attribute of EMPLOYEE:
Works_on (Project, Hours)

• or alternatively
• Multivalued composite attribute of PROJECT:
Workers (Employee, Hours).
• We choose the first alternative in Figure 3.8;
Weak Entity Types
• Weak entity types: Entity types that do not have
key attributes of their own and their identification
is dependent on another entity type..
• Strong entity types: that do have a key attribute.
• Always has a total participation constraint
(existence dependency) with respect to its
identifying relationship:
• A weak entity cannot be identified without an owner
entity.
Weak Entity
Constraints on Binary
Relationship Types
• Constraint: each employee must work for exactly
one department.
• Cardinality Ratios for Binary Relationships.
• Maximum number of relationship instances that an
entity can participate in.
• Cardinality Ratio (specifies maximum participation)
• One-to-one (1:1)
• One-to-many (1:N) or
• Many-to-one (N:1)
• Many-to-many (M:N)
• The UNIVERSITY database keeps track of the university’s
operations, including students, professors, departments, and
courses. The university is organized into departments, each
with a unique name and a unique code. Each department is
headed by a professor, and the database records the start
date of the professor’s leadership. Departments are also
associated with multiple buildings where their offices and
classrooms are located.
• Each department offers several courses, each identified by a
unique course code, a title, and a description. Courses also
have a specified number of credits. A course may be taught
by one or more professors and may have multiple sections.
Each section is uniquely identified by a section number and
is assigned a specific room and schedule.
• Professors have a unique employee ID, along with other
information such as their name, address, specialization, and salary.
Professors are assigned to one department but can teach courses
in other departments. They may also supervise research projects,
which include details like the project name, a unique code, a
description, and the funding allocated to the project.
• Students are uniquely identified by their student ID and have
personal information recorded, such as name, address, email,
gender, date of birth, and enrollment year. Students enroll in
multiple courses, and the database keeps track of the semester,
grade, and instructor for each course they take. Each student has
an assigned advisor, who is a professor from their department.
• The database also stores information about research projects
conducted by professors and students. Each project is identified by
a unique code, has a specific name and description, and is funded
by an external or internal source with a specified budget.
• To support scholarship programs, the database includes
records of students receiving scholarships. For each
dependent scholarship, the database stores details such
as the scholarship name, amount, type, and duration of
funding. Additionally, students may receive scholarships
from multiple funding sources.
• The system ensures that all relationships and
constraints are maintained, such as students enrolling
in courses across departments, professors teaching
multiple courses, and departments managing multiple
courses and projects. This structure allows for the
effective management and retrieval of university data.
Weak Entity Types
• A weak entity type normally has a partial key, which
is the attribute that can uniquely identify weak
entities. i.e., Name, Birthdate etc.
• Example:
• A DEPENDENT entity is identified by the dependent’s first name,
and the specific EMPLOYEE with whom the dependent is related
• Name of DEPENDENT is the partial key
• DEPENDENT is a weak entity type
• EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF
Relationship Types
• 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
• Degree of a Relationship Type: number of
participating entity types.
• i.e. WORKS_FOR relationship is of degree two (binary).
• Binary degree of relationship is most common.
• Recursive relationships or self-referencing
relationships: same entity type participates more
than once in a relationship type in different roles
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
Refining the initial design by introducing
relationships

• The initial design is typically not complete

• Some aspects in the requirements will be
represented as relationships
• ER model has three main concepts:
• Entities (and their entity types and entity sets)
• Attributes (simple, composite, multivalued)
• Relationships (and their relationship types and
relationship sets)

Slide 3- 33
Relationships and Relationship Types (1)

• A relationship relates two or more distinct entities with a

specific meaning.
• For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong manages the Research
DEPARTMENT.
• Relationships of the same type are grouped or typed into a
relationship type.
• For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
• The degree of a relationship type is the number of
participating entity types.
• Both MANAGES and WORKS_ON are binary relationships.

Slide 3- 34
 Relationship Types
• Relationship Type:
• Is the schema description of a relationship
• Identifies the relationship name and the participating entity types
• Also identifies certain relationship constraints.
• 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;
• the attribute Supervisor of EMPLOYEE refers to another employee (the one
who supervises this employee);
• the attribute Department of EMPLOYEE refers to the department for which
the employee works; and so on.
• Relationship Set:
• The current set of relationship instances represented in the database
• The current state of a relationship type
Participation Constraints and
Existence Dependencies
• 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 participation constraints
• Total Participation/ Existence: Employee must work for
department otherwise the employee entity does not
exist.
• Partial Participation: department must have a single
manager to manage the department. Manager instances
comes from the employee instance set.
• Structural Constraints: cardinality ratio and
participation constraints.
Attributes of Relationship Types
• Relationship
types can
also have
attributes.
Attributes of Relationship Types
• Attributes of 1:1 or 1:N 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 (many-to-many) relationship types,
• Some attributes may be determined by the combination
of participating entities, not by any single entity.
• Such attributes must be specified as relationship
attributes. An example is the Hours attribute of the M:N
relationship WORKS_ON
Attributes of Relationship Types
• The number of hours per week an employee
currently works on a project is determined by an
employee-project combination and not separately
by either entity.
Refining the ER Design for the COMPANY
Database
Alternative (min, max) notation
for relationship structural
constraints:
• Specified on each participation of an entity type E in a relationship type R
• Specifies that each entity e in E participates in at least min and at most max
relationship instances in R
• Default(no constraint): min=0, max=n (signifying no limit)
• Must have min≤max, min≥0, max ≥1
• Derived from the knowledge of mini-world constraints
• Examples:
• A department has exactly one manager and an employee can manage at
most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in MANAGES
• An employee can work for exactly one department but a department can
have any number of employees.
• Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
• Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
• The numbers mean that for each entity e in E, e
must participate in at least min and at most max
relationship instances in R at any point in time.
• In this method, min = 0 implies partial participation,
whereas min > 0 implies total participation.
The (min,max) notation for
relationship constraints

Read the min,max numbers next to the entity

type and looking away from the entity type
COMPANY ER
Schema Diagram
using (min, max)
notation
Other
alternative
diagrammatic
notations
Another Example: A UNIVERSITY
Database
• To keep track of the enrollments in classes and
student grades, another database is to be designed.
• It keeps track of the COLLEGEs, DEPARTMENTs
within each college, the COURSEs offered by
departments, and SECTIONs of courses,
INSTRUCTORs who teach the sections etc.
UNIVERSITY
database
conceptual
schema ©2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 50
Explore more examples of ER
Diagram
• https://www.oreilly.com/library/view/learning-mys
ql/0596008643/ch04s04.html
 Some of the Automated Database
Design Tools (Note: Not all may be on the market now)
COMPANY TOOL FUNCTIONALITY
Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration, space and security
management
Oracle Developer 2000/Designer 2000 Database modeling, application development
Popkin System Architect 2001 Data modeling, object modeling, process modeling,
Software structured analysis/design
Platinum Enterprise Modeling Suite: Data, process, and business component modeling
(Computer Erwin, BPWin, Paradigm Plus
Associates)
Persistence Inc. Pwertier Mapping from O-O to relational model

Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA
Resolution Ltd. Xcase Conceptual modeling up to code maintenance
Sybase Enterprise Application Suite Data modeling, business logic modeling
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++
Slide 3- 52