Entity Relationship (ER)
Diagrams
Design Phases
The initial phase of database design is to characterize fully the data
needs of the prospective database users.
Next, the designer chooses a data model and, by applying the
concepts of the chosen data model, translates these requirements into
a conceptual schema of the database.
A fully developed conceptual schema also indicates the functional
requirements of the enterprise. In a “specification of functional
requirements”, users describe the kinds of operations (or transactions)
that will be performed on the data.
Design Phases (Cont.)
The process of moving from an abstract data model to the
implementation of the database proceeds in two final design
phases.
Logical Design – Deciding on the database schema.
Database design requires that we find a “good” collection
of relation schemas.
Business decision – What attributes should we record
in the database?
Computer Science decision – What relation schemas
should we have and how should the attributes be
distributed among the various relation schemas?
Physical Design – Deciding on the physical layout of the
database
Design Approaches
Entity Relationship Model
Models an enterprise as a collection of entities and relationships
Entity: a “thing” or “object” in the enterprise that is
distinguishable from other objects
– Described by a set of attributes
Relationship: an association among several entities
Represented diagrammatically by an entity-relationship diagram:
Normalization Theory
Formalize what designs are bad, and test for them
Outline of the ER Model
ERD
The purpose of an ERD is to capture the richest possible
understanding of the meaning of data necessary for an information
system or organization.
ERDs are made from Entities, Attributes, and Relations.
University Entity-Relationship
Diagram
ER model -- Database Modeling
The ER data mode was developed to facilitate database design by
allowing specification of an enterprise schema that represents the
overall logical structure of a database.
The ER model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema.
Because of this usefulness, many database-design tools draw on
concepts from the ER model.
The ER data model employs three basic concepts:
entity sets,
relationship sets,
attributes.
The ER model also has an associated diagrammatic
representation, the ER diagram, which can express the overall
logical structure of a database graphically.
Entity Sets
An entity is an object that exists and is distinguishable from
other objects.
Example: specific person, company, event, plant
An entity set is a set of entities of the same type that share
the same properties.
Example: set of all persons, companies, trees, holidays
An entity is represented by a set of attributes; i.e., descriptive
properties possessed by all members of an entity set.
Example:
instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
A subset of the attributes form a primary key of the entity
set; i.e., uniquely identifiying each member of the set.
Entity Sets -- instructor and student
instructor_ID instructor_name student-ID student_name
Relationship Sets
A relationship is an association among several entities
Example:
44553 (Peltier) advisor 22222 (Einstein)
student entity relationship set instructor entity
A relationship set is a mathematical relation among n 2 entities, each
taken from entity sets
{(e1, e2, … en) | e1 E1, e2 E2, …, en En}
where (e1, e2, …, en) is a relationship
Example:
(44553,22222) advisor
Relationship Set advisor
Relationship Sets (Cont.)
An attribute can also be associated with a relationship set.
For instance, the advisor relationship set between entity sets
instructor and student may have the attribute date which tracks when
the student started being associated with the advisor
Complex Attributes
Attribute types:
Simple and composite attributes.
Single-valued and multivalued attributes
Example: multivalued attribute: phone_numbers
Derived attributes
Can be computed from other attributes
Example: age, given date_of_birth
Domain – the set of permitted values for each attribute
Composite Attributes
Redundant Attributes
Suppose we have entity sets:
instructor, with attributes: ID, name, dept_name, salary
department, with attributes: dept_name, building, budget
We model the fact that each instructor has an associated
department using a relationship set inst_dept
The attribute dept_name appears in both entity sets. Since
it is the primary key for the entity set department, it
replicates information present in the relationship and is
therefore redundant in the entity set instructor and needs to
be removed.
BUT: when converting back to tables, in some cases the
attribute gets reintroduced, as we will see later.
E-R Diagrams
Figure 3.14 Summary of ER diagram notation
Entity Sets
Entities can be represented graphically as follows:
• Rectangles represent entity sets.
• Attributes listed inside entity rectangle
• Underline indicates primary key attributes
Relationship Sets
Diamonds represent relationship sets.
Cardinality Constraints
We express cardinality constraints by drawing either a directed line
(), signifying “one,” or an undirected line (—), signifying “many,”
between the relationship set and the entity set.
One-to-one relationship between an instructor and a student :
A student is associated with at most one instructor via the
relationship advisor
A student is associated with at most one department via
stud_dept
One-to-Many Relationship
one-to-many relationship between an instructor and a student
an instructor is associated with several (including 0) students
via advisor
a student is associated with at most one instructor via advisor,
Many-to-One Relationships
In a many-to-one relationship between an instructor and a student,
an instructor is associated with at most one student via
advisor,
and a student is associated with several (including 0)
instructors via advisor
Many-to-Many Relationship
An instructor is associated with several (possibly 0) students via
advisor
A student is associated with several (possibly 0) instructors via
advisor
Total and Partial Participation
Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set
participation of student in advisor relation is total
every student must have an associated instructor
Partial participation: some entities may not participate in any relationship in the relationship set
Example: participation of instructor in advisor is partial
ER schema diagram for the company database
E-R Diagram for a University Enterprise
name
ssn lot
Employees
name
ssn lot
since
name dname
Employees
ssn lot did budget
super- subor-
visor dinate
Employees Works_In Departments
Reports_To
since
name dname
ssn lot did budget
0,M 1,M
Employees Manages Departments
1,1 1,M
Works_In
since
Starting an ERD
1. Define the Entities.
2. Define the Relationships.
3. Add attributes to the relationships.
4. Add cardinality to the relationships.
5. Don’t forget to use proper naming conventions and symbol
representation.
Entity Types
(Naming Guidelines)
Entity type name should be:
A singular noun and in capital letters.
Descriptive and specific to the organization.
Concise.
Named for the result of the event, not the activity or process of
the event.
Entity Types
(Defining Guidelines)
An Entity type definition should:
Include a statement of what the unique characteristics are for each
instance.
Make clear what entity instances are included and not included.
Include a description of when an instance of the entity type is
created and deleted.
Specify when an instance might change into an instance of
another entity type.
Specify what history is to be kept about entity instances.
Attributes
(Naming Guidelines)
An attribute name:
Should be a noun and capitalize the first letter of each word.
(Example: Student_ID.)
Should be unique.
Should follow a standard format. (Example: Student_GPA, not
GPA_of_Student.)
Similar attributes of different entity types should use similar but
distinguished names.
Example: Faculty_Residence_City_Name and
Student_Residence_City_Name
Attributes
(Defining Guidelines)
An attribute definition should:
State what the attribute is and why it is important.
Make clear what is and isn’t included in the attribute's value.
Define any aliases.
Indicate if the attribute is required or not.
Indicate any relationships with other attributes.
Relationships
(Naming Guidelines)
A relationship definition should Explain:
What action is being taken and why it is important.
If there is any optional participation.
The history that is kept in the relationship.
What any restrictions on participation in the relationship.
For example: An EMPLOYEE may only be able to participate
in two PROJECTS.
