Introduction to
Entity
Relationship
Modeling
Entity Relationship (E-R) Modeling
ISM 318
Dr. Hamid Nemati
Entity Relationship (E-R) Modeling
Introduction to
Entity
Relationship
Modeling
4
Understand basic modeling concepts
4
Data Models: Degrees of Data Abstraction
Understand the entity relationship model
A Comparison of E-R Modeling Symbols
4 Learn how to develop an E-R diagram
4
4
Basic Modeling Concepts
l
l
Introduction to
Entity
Relationship
Modeling
l
l
Database design is both art and science.
A data model is the relatively simple
representation, usually graphic, of complex realworld data structures. It represents data structures
and their characteristics, relations, constraints, and
transformations.
The database designer usually employs data models
as communications tools to facilitate the interaction
among the designer, the applications programmer,
and the end user.
A good database is the foundation for good
applications.
Data Models: Degrees of Data Abstraction
l
Based on their levels of abstraction
u
u
Introduction to
Entity
Relationship
Modeling
u
Conceptual Model
External Model
Internal Model
Data Models: Degrees of Data Abstraction
l
The Conceptual Model
u
Introduction to
Entity
Relationship
Modeling
u
u
u
The conceptual model represents a global view of
the data. It is an enterprise-wide representation of
data as viewed by high-level managers.
Entity-Relationship (E-R) model is the most widely
used conceptual model.
The conceptual model forms the basis for the
conceptual schema.
The conceptual model is independent of both
software (software independence) and hardware
(hardware independence).
Data Models: Degrees of Data Abstraction
Introduction to
Entity
Relationship
Modeling
A Conceptual Schema for Tiny College
Data Models: Degrees of Data Abstraction
l
The Internal Model
u
Introduction to
Entity
Relationship
Modeling
u
u
The internal model adapts the conceptual model to a
specific DBMS (e.g., hierarchical, network, and
relational).
The internal model is software-dependent.
Development of the internal model is especially
important to hierarchical and network database
models.
Data Models: Degrees of Data Abstraction
Introduction to
Entity
Relationship
Modeling
A Division of an Internal Model into External Models That Are
Represented by External Schemas
Data Models: Degrees of Data Abstraction
l
The External Model
u
Introduction to
Entity
Relationship
Modeling
u
The external model is the end user’s view of the data
environment.
Each external model is then represented by its own
external schema.
CREATE VIEW CLASS_VIEW AS
SELECT (CLASS_ID, CLASS_NAME,
PROF_NAME, CLASS_TIME, ROOM_ID)
FROM CLASS, PROFESSOR, ROOM
WHERE CLASS.PROF_ID = PROFESSOR.PROF_ID
AND CLASS.ROOM_ID = ROOM.ROOM_ID;
Data Models: Degrees of Data Abstraction
l
The External Model
u
Advantages of Using External Schemas
l
Introduction to
Entity
Relationship
Modeling
l
l
l
The use of external schemas makes application program
development much simpler.
The use of external schemas facilitates the designer’s task
by making it easier to identify specific data required to
support each business unit’s operations.
The existence of external models makes the designer’s job
easier by providing feedback about the conceptual model’s
adequacy.
The creation of external models helps to ensure security
constraints in the database design.
Data Models: Degrees of Data Abstraction
Introduction to
Entity
Relationship
Modeling
The External Models for Tiny College
Data Models: Degrees of Data Abstraction
l
The Physical Model
u
Introduction to
Entity
Relationship
Modeling
u
u
The physical model operates at the lowest level of
abstraction, describing the way data is saved on
storage media such as disks or tapes.
It requires the definition of both the physical storage
devices and the access methods required to reach the
data within those storage devices.
The physical model is both software and hardwaredependent.
The Entity Relationship (E-R) Model
l
E-R model is commonly used to:
u
Introduction to
Entity
Relationship
Modeling
u
u
Translate different views of data among managers,
users, and programmers to fit into a common
framework.
Define data processing and constraint requirements
to help us meet the different views.
Help implement the database.
The Entity Relationship (E-R) Model
l
E-R Model Components
u
Entities
l
Introduction to
Entity
Relationship
Modeling
l
u
u
In E-R model an entity refers to the entity set, not an entity
occurrence.
An entity is represented by a rectangle containing the
entity’s name.
Attributes
Relationships
The Entity Relationship (E-R) Model
l
Attributes
u
Introduction to
Entity
Relationship
Modeling
u
u
u
u
Attributes are represented by ovals and are
connected to the entity with a line.
Each oval contains the name of the attribute it
represents.
Attributes have a domain -- the attribute’s set of
possible values.
Attributes may share a domain.
Primary keys are underlined.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
The Attributes of the STUDENT Entity
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
Basic E-R Model Entity Presentation
The Entity Relationship (E-R) Model
l
Introduction to
Entity
Relationship
Modeling
Classes of Attributes
u
A simple attribute cannot be subdivided.
u
A composite attribute can be further subdivided to
yield additional attributes.
l
l
Examples: Age, Sex, and Marital status
Examples:
v
v
u
ADDRESS î Street, City, State, Zip
PHONE NUMBER î Area code, Exchange number
A derived attribute is not physically stored within
the database; instead, it is derived by using an
algorithm.
l
Example: AGE can be derived from the data of birth and
the current date.
The Entity Relationship (E-R) Model
l
Classes of Attributes
u
Introduction to
Entity
Relationship
Modeling
A single-valued attribute can have only a single
value.
l
Examples:
v
v
u
A person can have only one social security number.
A manufactured part can have only one serial number.
Multivalued attributes can have many values.
l
Examples:
v
v
l
A person may have several college degrees.
A household may have several phones with different
numbers
Multivalued attributes are shown by a double line
connecting to the entity.
The Entity Relationship (E-R) Model
l
Multivalued Attribute in Relational DBMS
u
Introduction to
Entity
Relationship
Modeling
u
The relational DBMS cannot implement multivalued
attributes.
Possible courses of action for the designer
l
l
Within the original entity, create several new attributes, one
for each of the original multivalued attribute’s components
(See Figure 4.8).
Example:
Y
l
CAR_COLOR î
CAR_TOPCOLOR, CAR_BODYCOLOR,
CAR_TRIMCOLOR
Create a new entity composed of the original multivalued
attribute’s components.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
Splitting the Multivalued Attribute into New Attributes
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
A New Entity Set Composed of
a Multivalued Attribute’s Components
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
A Derived Attribute
The Entity Relationship (E-R) Model
l
Relationships
u
Introduction to
Entity
Relationship
Modeling
u
u
A relationship is an association between entities.
Relationships are represented by diamond-shaped
symbols.
A relationship’s degree indicates the number of
associated entities or participants (see Figure 4.12).
l
l
l
A unary relationship exists when an association is
maintained within a single entity. (Recursive relationship)
A binary relationship exists when two entities are
associated. (Most common)
A ternary relationship exists when three entities are
associated.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
An Entity Relationship
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
Three Types of Relationships
The Entity Relationship (E-R) Model
l
Connectivity
u
Introduction to
Entity
Relationship
Modeling
The term connectivity is used to describe the
relationship classification (e.g., one-to-one, one-tomany, and many-to-many).
Connectivity in an E-R Diagram
The Entity Relationship (E-R) Model
l
Cardinality
u
Introduction to
Entity
Relationship
Modeling
u
Cardinality expresses the specific number of entity
occurrences associated with one occurrence of the
related entity.
The actual number of associated entities is usually a
function of an organization’s policy.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
Cardinality in an E-R Diagram
The Entity Relationship (E-R) Model
l
Existence Dependency
u
Introduction to
Entity
Relationship
Modeling
u
If an entity’s existence depends on the existence of
one or more other entities, it is said to be existencedependent.
Example:
l
the existence of an occurrence of CRS_CODE in the
COURSE table is dependent on CRS_CODE in the
CLASS table.
l
That is, no class can be offered for a course that doesn’t
exist.
The Entity Relationship (E-R) Model
l
Relationship Participation
u
Introduction to
Entity
Relationship
Modeling
u
The participation is optional if one entity occurrence
does not require a corresponding entity occurrence
in a particular relationship.
An optional entity is shown by a small circle on the
side of the optional entity.
E-R Diagram with Optional Entity
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
CLASS Is Optional to COURSE
COURSE and CLASS in a Mandatory Relationship
The Entity Relationship (E-R) Model
l
Weak Entities
u
A weak entity is one that
l
Introduction to
Entity
Relationship
Modeling
l
u
u
is existence-dependent and
has a primary key that is partially or totally derived from
the parent entity in the relationship.
The existence of a weak entity is indicated by a
double rectangle.
The weak entity inherits all or part of its primary key
from its strong counterpart.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
A Weak Entity in an E-R Diagram
The Entity Relationship (E-R) Model
Table Name: EMPLOYEE
Introduction to
Entity
Relationship
Modeling
Table Name: DEPENDENT
An Illustration of the Weak Relationship between
DEPENDENT and EMPLOYEE
The Entity Relationship (E-R) Model
l
Recursive Entities
u
Introduction to
Entity
Relationship
Modeling
u
u
A recursive entity is one in which a relationship
can exist between occurrences of the same entity set.
A recursive entity is found within a unary
relationship. (See Figure 4.19)
Examples:
l
l
l
l
Database Table 4.7 -- Unary Recursive Relationship
Database Table 4.8 -- M:N Recursive Relationship
Database Table 4.9 -- M:N Recursive Relationship
Database Table 4.10 -- 1:M Recursive Relationship
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
An E-R Representation of Recursive Relationships
The 1:1 Recursive Relationship
“EMPLOYEE Is Married to EMPLOYEE”
The Entity Relationship (E-R) Model
l
Composite Entities
u
Introduction to
Entity
Relationship
Modeling
u
u
A composite entity is composed of the primary keys
of each of the entities to be connected. The
composite entity serves as a bridge between the
related entities.
The composite entity may contain additional
attributes.
Example:
l
ENROLL table in Database Table 4.1 bridges STUDENT
and CLASS.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
The M:N Relationship between STUDENT and CLASS
The Entity Relationship (E-R) Model
u
Introduction to
Entity
Relationship
Modeling
u
u
A class may exist even though it contains no
students at all; i.e., STUDENT is optional to
CLASS. When the M:N relationship is decomposed
into two 1:M relationships through ENROLL, the
optionality must be transferred to ENROLL (See
Figure 4.21).
To be classified as a STUDENT, a person must be
enrolled in at least one CLASS; i.e, CLASS is
mandatory to STUDENT.
A class can occur more than once in the ENROLL
table.
The Entity Relationship (E-R) Model
Introduction to
Entity
Relationship
Modeling
A Composite Entity in the E-R Diagram
Developing an E-R Diagram
l
Introduction to
Entity
Relationship
Modeling
l
The process of database design is an iterative rather
than a linear or sequential process.
Information for database design is gathered by
interviewing the end users and examining the
business forms and reports.
Developing an E-R Diagram
l
Converting an E-R Model into a Database
Structure for ARTIST Database
u
Introduction to
Entity
Relationship
Modeling
u
u
A painter might paint many paintings. The
cardinality is (1,N) in the relationship between
PAINTER and PAINTING.
Each painting is painted by one (only one) painter.
A painting might (or might not) be exhibited in a
gallery; i.e., the GALLERY is optional to
PAINTING.
Developing an E-R Diagram
Introduction to
Entity
Relationship
Modeling
Figure 4.28
Developing an E-R Diagram
l
Introduction to
Entity
Relationship
Modeling
Summary of Table Structures and Special
Requirements for the ARTIST database
PAINTER(PRT_NUM, PRT_LASTNAME,
PRT_FIRSTNAME, PRT_INITIAL, PTR_AREACODE,
PRT_PHONE)
GALLERY(GAL_NUM, GAL_OWNER, GAL_AREACODE,
GAL_PHONE, GAL_RATE)
PAINTING(PNTG_NUM, PNTG_TITLE, PNTG_PRICE,
PTR_NUM, GAL_NUM)
Developing an E-R Diagram
Table 4.2 Data Dictionary for the ARTIST Database
Introduction to
Entity
Relationship
Modeling
Developing an E-R Diagram
l
Introduction to
Entity
Relationship
Modeling
SQL Commands to Create Tables for ARTIST
database
CREATE TABLE PAINTER (
PTR_NUM
SMALLINT
NOT NULL UNIQUE,
PRT_LASTNAME CHAR(15)
NOT NULL,
PTR_FIRSTNAMECHAR(15),
PTR_INITIAL CHAR(1),
PTR_AREACODE CHAR(3),
PTR_PHONE
CHAR(8),
PRIMARY KEY(PTR_NUM));
Developing an E-R Diagram
Introduction to
Entity
Relationship
Modeling
CREATE TABLE GALLERY (
GAL_NUM
SMALLINT
NOT NULL UNIQUE,
GAL_OWNER
CHAR(35),
GAL_AREACODE CHAR(3)
NOT NULL,
GAL_PHONE
CHAR(8)
NOT NULL,
PRIMARY KEY(GAL_NUM));
Developing an E-R Diagram
CREATE TABLE PAINTING (
PNTG_NUM
SMALLINT
NOT NULL UNIQUE,
PNTG_TITLE
CHAR(35),
PNTG_PRICE
MONEY,
PTR_NUM
SMALLINT
NOT NULL,
GAL_NUM
SMALLINT,
PRIMARY KEY(PNTG_NUM)
FOREIGN KEY(PTR_NUM) RERERENCES PAINTER
ON DELETE RESTRICT
ON UPDATE CASCADE
FOREIGN KEY(GAL_NUM) REFERENCES GALLERY
ON DELETE RESTRICT
ON UPDATE CASCADE);
Introduction to
Entity
Relationship
Modeling
Developing an E-R Diagram
l
General Rules Governing Relationships among
Tables
u
Introduction to
Entity
Relationship
Modeling
u
All primary keys must be defined as NOT NULL.
Define all foreign keys to conform to the
requirements for the appropriate binary relationship.
l
l
l
l
1:M Relationship
Weak Entity
M:N Relationship
1:1 Relationship
SQL Foreign Key Requierments
l
DELETE RESTRICT:
u
Introduction to
Entity
Relationship
Modeling
l
DELETE CASCADE:
u
l
Restrict the ability to DELETE a row from a table if there is a
foreign key in another table that references it.
l We can only delete a painter from the PAINTER table if
there is no foreign key in another table that requires the
painter’s existance.
Delete the row with matching foreign key columns over the
referenced table
l When an item is droped from the inventory table it is
automatically droped from the orders table too.
DELETE SET NULL:
u
if a dorm is deleted, the student can not remain in that room
and will, in effect, have no room (NULL) until (s)he is
reassinged to another room.
Developing an E-R Diagram
l
1:M Relationships
u
Introduction to
Entity
Relationship
Modeling
Create the foreign key by putting the primary key of
the “one” in the table of the “many”.
l
l
u
“One” -- Parent table
“Many” -- Dependent table
Relationship Participation:
l
l
l
If both sides are MANDATORY.
If both sides are OPTIONAL.
If one side is OPTIONAL and one side is MANDATORY.
Developing an E-R Diagram
l
Weak Entity
u
Introduction to
Entity
Relationship
Modeling
u
l
Put the key of the parent table (strong entity) in the
weak entity.
The weak entity relationship conforms to the same
rules as the 1:M relationship, except foreign key
restrictions.
M:N Relationship
u
Convert the M:N relationship to a composite
(bridge) entity consisting of the parent tables’
primary keys.
Developing an E-R Diagram
l
1:1 Relationships
u
Introduction to
Entity
Relationship
Modeling
If both entities are in mandatory participation in the
relationship and they do not participate in other
relationships, it is most likely that the two entities
should be part of the same entity.
Developing and Building the E-R
Model
l
Introduction to
Entity
Relationship
Modeling
Carlos Enterprises
u The company owns several divisions, but each division belongs
to the same company.
u A division can operate several projects, but each project
belongs to a single division. Some divisions do not operate
projects at all.
u A division has many employees, but each employee is assigned
to only one division. To be classified as a division, at least
twenty-five employees must be assigned to it.
u An employee might be assigned to many projects (or to none at
all), and each project has at least one employee assigned to it.
u An employee may or may not have dependents.
u Carlos Enterprises maintains a list of desired skills, but not all
of these skills are currently represented in the employee pool.
Developing an E-R Diagram
u
Introduction to
Entity
Relationship
Modeling
Table Structures:
DIVISION (DIV_NUM, DIV_NAME, EMP_NUM)
PROJECT (PROJ_NUM, PROJ_NAME, DIV_NUM,
PROJ_TOTAL_HOURS, PROJ_COST)
EMPLOYEE (EMP_NUM, DIV_NUM, EMP_LNAME,
EMP_FNAME, EMP_INITIAL, EMP_HIREDATE,
EMP_DOB)
SKILL (SKILL_CODE, SKILL_DESCRIPTION)
TRAINING (EMP_NUM, SKILL_CODE,
TRAIN_EXPERIENCE)
DEPENDENT (EMP_NUM, DEP_NUM, DEP_FNAME,
DEP_DOB)
ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
A Comparison of E-R Modeling Symbols
Introduction to
Entity
Relationship
Modeling
Figure 4.28
AComparison of
E-R Modeling Symbols
A Comparison of E-R Modeling Symbols
Introduction to
Entity
Relationship
Modeling
A Comparison of E-R Modeling Symbols
Introduction to
Entity
Relationship
Modeling
A Comparison of E-R Modeling Symbols
Introduction to
Entity
Relationship
Modeling
Challenges of DB Design: Conflicting Goals
l
Conflicting Goals
u
u
Introduction to
Entity
Relationship
Modeling
u
l
Design standards (design elegance)
Processing speed
Information requirements
Design Considerations
u
u
u
u
u
Logical requirements and design conventions
End user requirements; e.g., performance, security,
shared access, data integrity
Processing requirements
Operational requirements
Documentation