Introduction to Database

Systems

Entity-Relationship Model (I)

 Semantic Modeling
➢A class of data models
➢ Conveys semantic meaning
➢ Implements databases more intelligently
➢ Support more sophisticated user
interfaces (SQL queries)
➢ Research started in 1970s and early
1980s
➢ Other names are data modeling, E/R
modeling, E-modeling
 Top-Down Methodology
➢ Design methodologies that are based on
semantic modeling ideas are often
referred to as Top-Down methodologies,
because they start at a high level of
abstraction with real world constructs or
entities and finish at the low level of
abstraction represented by a specific
concrete database design
 Chen E/R Model
➢ Chen in 1976 introduced the E/R model
➢ The E/R model allows us to sketch the
design of a database informally.
➢ Designs are pictures called entity-
relationship diagrams.
➢ Fairly mechanical ways to convert E/R
diagrams to real implementations like
relational databases exist.
 Database Development
Requirements Requirements Natural
Analysis Specification Language

Conceptual Conceptual
Informal
Design Model

Logical Relational Formal

Design Model
DBMS-independent
Database DBMS-specific
Building Database

Physical
Operation, Mainte- Evolving
nance, & Tuning Database
 Database Development (Cont.)
➢ Requirements Analysis
⚫ Collect and Analyze the requirements of the users.
➢ Conceptual Design
⚫ Design a conceptual model (schema), e.g., ER model.
➢ Logical Design
⚫ Translate the ER model into a relational model (schema).
⚫ Normalization
➢ Database Building
⚫ Build the database and write application programs.
➢ Operation, Maintenance, & Tuning
⚫ Use, maintain, and “tune” the database.
 Logical Design
➢ Translate an ER schema into a relational
schema.
⚫ Entity
⚫ Relationship
⚫ Attribute
⚫ Subtype

➢ Normalization
⚫ To ensure you have a “good” design.
 SUMMARY OF ER-DIAGRAM
NOTATION
Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

E1 R E2 TOTAL PARTICIPATION OF E2 IN R

N CARDINALITY RATIO 1:N FOR E1:E2 IN R

E1 R E2

(min,max) STRUCTURAL CONSTRAINT (min, max) ON

R E
PARTICIPATION OF E IN R
 Example COMPANY
Database
➢ Requirements of the Company (oversimplified
for illustrative purposes)
⚫ The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
⚫ Each department controls a number of PROJECTs.
Each project has a name, number and is located at
a single location.
 Example COMPANY Database
(Cont.)
⚫We store each EMPLOYEE’s social security
number, address, salary, gender, and birthdate.
Each employee works for one department but may
work on several projects. We keep track of the
number of hours per week that an employee
currently works on each project. We also keep track
of the direct supervisor of each employee.
⚫Each employee may have a number of
DEPENDENTs. For each dependent, we keep track
of their name, gender, birthdate, and relationship to
employee.
ER DIAGRAM FOR THE COMPANY
DATABASE
 ER Model Concepts:
Entities and Attributes
➢ Entities - are specific objects or things in the mini-world
that are represented in the database; for example, the
EMPLOYEE John Smith, the Research DEPARTMENT,
the ProductX PROJECT
➢ Attributes are properties used to describe an entity; for
example, an EMPLOYEE entity may have a Name, SSN,
Address, gender, BirthDate
➢ A specific entity will have a value for each of its
attributes; for example, a specific employee entity may
have Name=‘John Smith’, SSN=‘123456789’,
Address=‘731 Fondren, Houston, TX’, Gender=‘M’,
BirthDate=‘09-JAN-75’
 Types of Attributes
➢ Domain: Possible values for an attribute; for
example ‘M’ and ‘F’ for the Gender attribute.
➢ Simple: Each entity has a single atomic value
for the attribute; for example SSN or Gender
➢ Composite: The attribute may be composed of
several components; for example, Address
(Apt#, House#, Street, City, State, ZipCode,
Country) or Name(FirstName, MiddleName,
LastName). Composition may form a hierarchy
where some components are themselves
composite.
 Types of Attributes
➢ Multi-valued: An entity may have multiple values
for that attribute; for example, Color of a CAR or
PreviousDegrees of a STUDENT. Denoted as
{Color} or {PreviousDegrees}.
➢ In general, composite and multi-valued attributes
may be nested arbitrarily to any number of levels
although this is rare. For example,
PreviousDegrees of a STUDENT is a composite
multi-valued attribute denoted by
{PreviousDegrees(College, Year, Degree,
Field)}.
 Entity Types and Key Attributes
➢ Entities with the same basic attributes are
grouped or typed into an entity type. For
example, the EMPLOYEE entity type or
the PROJECT entity type.
➢ An attribute of an entity type for which
each entity must have a unique value is
called a key attribute of the entity type.
For example, SSN of EMPLOYEE.
 Entity Types and Key Attributes
➢ A key attribute may be composite. For example,
VehicleTagNumber is a key of the CAR entity
type with components (Number, State).
➢ An entity type may have more than one key. For
example, the CAR entity type may have two
keys:
⚫ VehicleIdentificationNumber (popularly called VIN)
and
⚫ VehicleTagNumber (Number, State), also known as
license_plate number.
 Relationships and Relationship Types
➢ 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.
Relationships and Relationship Types

➢ The degree of a relationship type is the number

of participating entity types. Both MANAGES
and WORKS_ON are binary relationships.

➢ More than one relationship type can exist with

the same participating entity types; for
examples, MANAGES and WORKS_FOR are
distinct relationships between EMPLOYEE and
DEPARTMENT participate.
Relationships and Relationship Types

➢ A relationship can relate two entities of the

same entity type ; for example, a SUPERVISION
relationship type relates one EMPLOYEE (in the
role of supervisee ) to another EMPLOYEE (in
the role of supervisor ). This is called a recursive
relationship type

➢ A relationship type can have attributes; for

example, HoursPerWeek of WORKS_ON; its
value for each relationship instance describes
the number of hours per week that an
EMPLOYEE works on a PROJECT.
 Structural Constraints & Roles
➢ Structural constraints on relationships:
⚫ Cardinality ratio (of a binary relationship):
⚫ 1:1, 1:N, N:1, or M:N.

➢ Participation constraint
⚫ (on each participating entity type): total (called
existence dependency ) or partial.