The Entity-Relationship Diagram

Overview of Database Design

• Conceptual design: (ER Model is used at this
stage.)
– What are the entities and relationships in the
enterprise?
– What information about these entities and relationships
should we store in the database?
– What are the integrity constraints or business rules that
hold?
– A database “schema” in the ER Model can be
represented pictorially (ER diagrams).
– We can map an ER diagram into a relational schema.
 ER Diagram
• Entity Relationship (ER) Diagram
– A detailed, logical representation of the entities,
associations and data elements for an organization or
business

– An entity-relationship (ER) diagram is a specialized graphic

that illustrates the interrelationships between entities in a
database.
 Framework for E/R
• The E/R model allows us to sketch database schema
designs
• Design is a serious business.
• The “boss” knows they want a database, but they
don’t know what they want in it.
• Sketching the key components is an efficient way to
develop a working database.

4
 Main constructors of ER

– Data entities

– Relationships

– Attributes
 ER Model Basics
• Entity: Real-world object distinguishable
from other objects. An entity is described (in
DB) using a set of attributes.
• An entity is shown in a rectangle.
• Entity Set: A collection of similar entities.
E.g., all employees.
– All entities in an entity set have the same set of
attributes. (Until we consider ISA hierarchies,
anyway!)
 Entities

• Examples of entities:
– Person: EMPLOYEE, STUDENT, PATIENT
– Place: STORE, WAREHOUSE
– Object: MACHINE, PRODUCT, CAR
– Event: SALE,REGISTRATION, RENEWAL
– Concept: ACCOUNT, COURSE
• Guidelines for naming and defining entity types:
– An entity type name is a singular noun
– An entity type should be descriptive and specific
– An entity name should be concise
– Event entity types should be named for the result of the event, not the
activity or process of the event.
An entity’s name should be:
• Unique in the entire organization; furthermore, try to avoid similar
names for different entities, such as PROJECT and PROJECTION.

Choose a non-confusing name for both.

PROJECT PROJECTION
If different terms are used to define the same thing under
different departments synonyms can be defined. For example,
some departments may call it a CUSTOMER while others may
call a CLIENT.

Finally one has to be chosen in database but when speaking to

different people we must choose their terms.
 Instances of entities
If you are not certain whether something is an entity or not, it
may help to ask yourself the question,

“What are the instances (examples)

of this entity?”
Validate Entities

To make sure your list includes real entities,

Here are some other ways:

Is its name a noun? Not all nouns represent entities, but all entity
names should be nouns.
Validate Entities

To make sure your list includes real entities,

Here are some other ways:

Does this entity have any attributes?

For example, if you think you have an entity named STUDENT, do you
need to store facts about students?
Name, Student Number, Address, Birth Date ....
YES, IT IS AN ENTITY.
 Validate Entities

To make sure your list includes real entities,

Here are some other ways:

If you think you have an entity called CUSTOMER NAME, ask the
same question: Does it have any facts, attributes to store? The
country of origin, number of wovels, meaning of the name ....
Are these really important facts to store in your database?

NOT! Then CUSTOMER NAME is not an entity.

Summary

• An entity is a thing of significance about which information needs to be

stored; a class or category of thing; a named thing.
• When considering whether something is an entity or not, it helps to
ask yourself the question, “What would some instances of this entity
be?”
• An entity’s name should be unique in the entire organization and
familiar to all.
• Once you have identified an entity and named it, you should diagram
it; the diagram pictorially represents entities, the vital business
relationships between them and the attributes to describe them.
• An attribute is any detail that serves to qualify, identify, classify,
quantify, or express the state of an entity.
 Logical DB Design: ER to Relational

• Entity sets to tables:

CREATE TABLE Employees
name (ssn CHAR(11),
ssn lot name CHAR(20),
lot INTEGER,
PRIMARY KEY (ssn))
Employees
 Attributes

• An attribute is a property or characteristic for an entity

or a relationship type.
• It is shown in an oval.

• Example of entity types and associated attributes:

STUDENT: Student_ID, Student_Name,
Home_Address, Phone_Number, Major
Guidelines for naming attributes

– An attribute name is a noun.

– An attribute name should be unique
– To make an attribute name unique and clear, each
attribute name should follow a standard format
– Similar attributes of different entity types should
use similar but distinguishing names.
 Simple and Composite attributes
• A simple(atomic) attribute is an attribute composed
of a single component with an independent
existence.
• can not be further subdivided into smaller
components.
• A composite attribute, sometimes called a group
attribute, is an attribute composed of multiple
components, each with an independent existence.
• The names chosen for composite attributes should
be descriptive and general
Composite Attribute
 Single-valued and Multi-valued attribute
• Single-valued attribute that holds a single value for
each occurrence of an entity type.
• Multi-valued attribute that holds multiple values for
each occurrence of an entity type.
• Multi-valued attributes are mapped by using additional
relation schema. For each multi-valued attribute A,
create a new relation R.
• This relation will include attribute corresponding to A
plus the primary key K of the entity type or relationship
type that has A as attribute. Combination of A and K
becomes primary key of R.
Example: multivalued attribute

Multivalued attribute… an employee

may have more than one skill.
 Derived attributes
• An attribute that represents a value that is derivable
from the value of a related attribute or set of
attributes, not necessarily in the same entity type.

• The values are held by some attributes may be

derived.

• The oval representing a derived attribute is drawn

with a dash line
 Candidate Keys

• Some tables contain more than one column (or

combination of columns –composite key) that can
act as a primary key. These columns all possess
the uniqueness property of a primary key. Here,
also, null values are not allowed. These columns
are called candidate keys. However, only one is
designated as the primary key

• All candidate keys which are not chosen as

"primary key" are Alternate keys.
 Primary Key
• A primary key is used to uniquely identify each
row in a table.

• this key does not allow null values and also does
not allow duplicate values.

• Primary keys can be specified either when the

table is created (using CREATE TABLE) or by
changing the existing table structure (using ALTER
TABLE).
 Example

• CREATE TABLE Student

(SID integer,
Last_Name varchar(30),
First_Name varchar(30),
PRIMARY KEY (SID));
 Foreign Key
• A foreign key is a field (or fields) that points to
the primary key of another table. The purpose
of the foreign key is to ensure referential
integrity of the data. In other words, only
values that are supposed to appear in the
database are permitted.
 Example
• create table Enroll (Student_SID integer,
Courses_CID char(10),
Foreign Key(Student_SID) references
Student(SID),
Foreign Key(Courses_CID)references
Courses(CID)
);
 Entity Type Key
• Every (regular) entity type has at least one key
• The entity type key is defined in a similar way as the relation
schema key
• To denote the primary key, underlining is used
• If a key has more than one attribute, it should be represented
as a composite attribute
• e.g.
Course
Subject
CourId NoOfpts PName
CourNo
 Relationships

Relationship: Association among two or more entities

Relationship Set: Collection of similar relationships.

Relationship name:
writes

Author Book

An author writes one or more books

A book can be written by one or more authors.
Guidelines for naming relationship
– Explain any restrictions on participation in the
relationship
– Explain extent of the history that is kept in the
relationship
– Explain whether an entity instance involved in a
relationship instance can transfer participation to
another relationship instance
– Graphically, a relationship is represented by a
diamond shaped box connecting associated entity
types
 ER Model Basics
since
name dname
ssn lot did budget

Employees Works_In Departments

CREATE TABLE Works_In(

ssn CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn)
REFERENCES Employees,
FOREIGN KEY (did)
REFERENCES Departments)
 Attributes on relationships

Sometimes it is useful to attach attributes to

a relationship
• to represent a certain characteristic or
property of that relationship
 Degree of Relationships

• Degree: number of entity types that participate in a relationship

• Three cases
– Unary: between two instances of one entity type
– Binary: between the instances of two entity types
– Ternary: among the instances of three entity types
– Quaternary: among the instances of three entity types
 Recursive Relationships

• A relationship may be defined between

entities of the same entity set
• Associations between entities of the same set
are called recursive
• Every entity in a relationship has a role
• In the case of a recursive relationship, the
roles should be shown explicitly
Example :Unary
Example: Ternary
Example-Quaternary
 Cardinality and Connectivity

• Relationships can be classified as either

• one – to – one
• one – to – many
Connectivity
• many – to –many
• many – to –one

• Cardinality : minimum and maximum number of

instances of Entity B that can (or must be) associated
with each instance of entity A.
 Connectivity

• Chen Model
1
– 1 to represent one.
– M to represent many M

• Crow’s Foot
One Mandatory one , means (1,1)

many

One or many
 Cardinality Ratio

b2 b1
E1 R E2

• The cardinality ratio of R is an expression of the form

b1 :b2
where b1 is the maximal number of E2 instances that
may be associated with an E1 instance, b2 is the
maximal number of E1 instances that may be
associated with an E2 instance, and b∈{1, N }
Cardinality Limits
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 Crow’s foot modell
One-to-one (1:1)

Man Woman

One-to-many (1:n)

Customer Order

Many-to-many (n:m)

Course Subject

NOTE: Every many to many relationship consists of two one to

many relationships working in opposite directions
 Participation Constraint
• The participation constraint specifies whether existence of an entity
depends on its association with another entity
• A participation constraint can be:
– Total when it models existence dependence,
– Partial
• Graphic representation ( | partial, || total)
• Mind that participation constraint is placed on that side of the relationship
where the considered entity belongs

1 1
HeadOfSchool Manages School
HOS

total partial
 Question for you
• Cardinality ratio and participation constraint are together
called structural constraint
• Cardinality ratio can be either 1 : 1, 1 : N, or M : N
• participation constraint can be either total or partial
• How many different structural constraints are there:
– 2
– 4
– 8
– 12
 Participation: Full/Partial
• It is likely that on any campus, not all students will drive an automobile

• To show that every automobile is driven by a student, but not every

student drives an automobile, we will enhance our model of ER diagrams
by putting a double line between the relationship diamond and the
AUTOMOBILE entity to indicate that every automobile is driven by one
student. Put another way, every automobile in the database participates
in the relationship.
• From the student side, we leave the line between the STUDENT entity and
the relationship as a single line to indicate that not every student drives an
automobile. Some students will not participate in the drive relationship
because they do not drive a car on campus. The single/double lines are
called participation constraints.
 Relationships of the Degree > 2

Student SPL Course

Lecturer

Instances of the SPL relationship type are triples (s, c, l ). The structural
constraints are determined by considering associations between:
• a (s, c ) pair and a l to determine cardinality ratio next to Lecturer, and
between a l and a (s, c ) pair to determine the participation constraint
of the Lecturer
• the same applies to a (s, l ) pair and a c for a Course instance, and a
•(l, c ) pair and a s for a Student instance
 Relationships of the Degree > 2
N N
Student SPL Course

Lecturer
Suppose each Course c is taught by only one lecturer l and each lecturer
teaches at least one Course. Then:
• each (s, c ) pair is associated with exactly one l, so the cardinality
ratio next to Lecturer will be 1, and the Lecturer has a total participation
constraint,
• it is natural to expect that each (l, c ) pair is associated with zero or more
than one students, and
• each (s, l ) pair with zero or more than one Course