Data Modeling: Entity

Relationship Model
Basic Constructs of E-R Modeling 2

 The ER model views the real world as a construct of

entities and association between entities.
 Entities
 Attributes
 Relationships
Entities 3

 Entities are the principal data object about which information is to be

collected. THEY CAN BE THOUGHT OF AS NOUNS.
 Entities are usually recognizable concepts, either concrete or
abstract, such as person, places, things, or events which have
relevance to the database.
 Entity set is a collection of similar types of entities.
 An entity set may contain entities with attributes sharing similar values.
 Examples are EMPLOYEES, PROJECTS, INVOICES.
 An entity is analogous to a table in the relational model.
Entities Contd 4

 An entity is a person, place, object, event or concept in the user

environment about which the organization wishes to maintain data.
 Examples are:
 Person: STUDENT, LECTURER, EMPLOYEE, PATIENT
 Place: STORE, WAREHOUSE, OFFICE, STATE
 Object: MACHINE, BUILDING, AUTOMOBILE
 Event: SALE, REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE, WORK CENTER
 5
Attributes
 Attributes are data objects that either identify or describe entities.
 A particular instance of an attribute is a value.
 For example, “OO Popoola" is one value of the attribute Name.
 The domain of an attribute is the collection of all possible values
an attribute can have. The domain of Name is a character string.
 Attributes can be classified as identifiers or descriptors.
 Identifiers, more commonly called keys, uniquely identifies an
instance of an entity.
 Descriptor describes a non-unique characteristics of an entity
instance.
 6
Relationships

 Represents an association between two or more entities.

 Relationships can be thought of as VERBS, linking two or more nouns.
 Examples: an owns relationship between a company and a computer; a supervises
relationship between an employee and a department.
 More examples
 Employees are assigned to projects
 Projects have subtasks
 Departments manage one or more projects
 Relationships are classified in terms of degree, connectivity, cardinality, and
existence.
 These concepts will be discussed later on.
Classifying Relationships 7

 Classified by:
i. degree,
ii. connectivity,
iii. cardinality,
iv. direction,
v. and existence
 Not all modeling methodologies use all these classifications.
 1. Degree of Relationships 8

 The number of entities associated with the relationship.

 The general form is n-ary relationship is the where the degree is n.
 Binary, and ternary ,where the degree is 2, and 3, respectively.
 Binary relationships, the association between two entities is the most common type in
the real world.
 A recursive relationship or unary relationship occurs when an entity is related to itself.
 Example might be "some employees are married to other employees".
 Ternary relationship involves three entities and is used when a binary relationship is
inadequate.
 Many modeling approaches recognize only binary relationships.
 Ternary or n-ary relationships are decomposed into two or more binary relationships.
Examples of degree of relationship 9

1. Unary relationship – only one entity

 An employee manages employees
2. Binary relationship – two entities involved
 A student registers for a course
3. Tenary relationship – three entities involved
 Vehicle parts are supplied by a vendor to a given warehouse
 10
2. Connectivity and Cardinality

 Connectivity of a relationship describes the mapping of associated

entity instances in the relationship.
 The values of connectivity are "one" or "many".
 Cardinality of a relationship is the actual number of related
occurrences for each of the two entities.
 The basic types of connectivity for relations are: one-to-one, one-to-
many, and many-to-many.
Connectivity: one-to-one (1:1) 11

 One-to-one (1:1) relationship is when at most one instance of a

entity A is associated with one instance of entity B.
 For example,
 “Employees in the company are each assigned their own office.”
 For each employee there exists a unique office and for each office
there exists a unique employee.
Connectivity: one-to-many (1:N) 12

 One-to-many (1:N) relationships is when for one instance of entity A,

there are zero, one, or many instances of entity B, but for one
instance of entity B, there is only one instance of entity A.
 Example:
 “A department has many employees”
 “Each employee is assigned to one department”
Connectivity: many-to-many (N:M) 13

 A many-to-many (M:N) relationship is when for one instance of entity A, there are
zero, one, or many instances of entity B and for one instance of entity B there are
zero, one, or many instances of entity A.
One entity from A can be associated with more than one entity from B and vice versa.
An example is:
 “Employees can be assigned to no more than two projects at the same time;
projects must have assigned at least three employees.”
 A single employee can be assigned to many projects; conversely, a single project
can have assigned to it many employees.
 Cardinality between employees and projects is 2
 Cardinality between projects and employees is 3
One – to – One, One – to – Many and Many – to – Many 14
Mapping

One-to-One One-to-Many Many-to-Many

3. Direction 15

 The direction of a relationship indicates the originating entity of a binary

relationship.
 The entity from which a relationship originates is the parent entity; the
entity where the relationship terminates is the child entity.
 The direction of a relationship is determined by its connectivity.
 In a one-to-one relationship the direction is from the independent entity
to a dependent entity. If both entities are independent, the direction is
arbitrary.
 With one-to-many relationships, the entity occurring once is the parent.
 The direction of many-to-many relationships is arbitrary.
 4. Existence 16

 Denotes whether the existence of an entity instance is dependent

upon the existence of another, related, entity instance.
 The existence of an entity in a relationship is defined as either
mandatory or optional.
 If an instance of an entity must always occur for an entity to be
included in a relationship, then it is mandatory.
For example “Every project must be managed by a single department".
 If the instance of the entity is not required, it is optional.
For example “Employees may be assigned to work on projects".
ER Notation 17

 There is no standard for representing data objects in ER diagrams.

 Each modeling methodology uses its own notation.
 The original notation used by Chen is widely used in academic textbooks and
journals but are rarely seen in either Computer-Aided Software Engineering
(CASE) tools or publications by non-academics.
 Today, there are a number of notations used, among the more common are
Bachman, Martin/Crow's foot, and IDEFIX.
 We will use Chen’s and Martin’s notation.
 Chen’s Notation 18


The entity relationship diagram was introduced by Chen in 1976.

In this ERD, entities are represented by a box (rectangle) and relationship
types are symbolized by a diamond.

A double rectangle and a double diamond represent a weak entity
type and a weak relationship,respectively.

Attributes are represented by oval symbols.

"Many" cardinality is indicated with the "N" near the entity's box, while a
"1" indicates "one".
Symbols of Chen’s notation 19


One – to – One One – to Many



Many – to – Many Entity and attributes
 Crow’s Foot Notation 20


The crow's foot notation
was invented by
Gordon Everest, who
originally used the term
"inverted arrow" but
now just calls it a "fork".

For cardinality, a fork or
crow's foot intuitively
indicates "many", by its
many "toes".
Entity and Attribute notation
21
Martin/Crow’s foot

 Entities are represented by labeled Entity Entity

rectangles. Attribute
Attribute
 The label is the name of the entity. Attribute
Entity names should be singular
nouns.
 Attributes, when included, are listed
inside the entity rectangle.
 Attributes which are identifiers are
underlined. Attribute names should
be singular nouns.
Relationship, cardinality and existence
22
notation
 Relationships are represented by a solid line connecting two entities. The name of the
relationship is written above the line.
 Cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is omitted,
the cardinality is one.
 Existence is represented by placing a circle or a perpendicular bar on the line.
 Mandatory existence is shown by the bar (looks like a 1) next to the entity for an instance is
required.
 Optional existence is shown by placing a circle next to the entity that is optional.

Multiplicity of many (optional) Multiplicity of one (optional)

Multiplicity of many (mandatory) Multiplicity of one (mandatory)

ER Notation (Crow’s Foot) example 23
ER Diagramming
Conventions 24

 The diagram shows the

relationship between a
person and a place of
birth:
 Each person must have
been born at one, and
only one, location, but
each location may have
had zero or more people
born at it.
 Assignment 25

 Draw the ER diagram for the following statements indicating the

following:
1. The Relationship
2. Cardinality
3. Existence
Employee is assigned workstation; not all employees are assigned
workstations.
A department may be responsible for many projects; but each
project is the responsibility of one department.
Employees maybe assigned to many projects; every project has
assigned at least one employee.
 26
Summary

 The Entity-Relationship Model is a conceptual data model that views the

real world as consisting of entities and relationships.
 The model visually represents these concepts by the Entity-Relationship
diagram.
 The basic constructs of the ER model are entities, relationships, and
attributes.
 Entities are concepts, real or abstract, about which information is collected.
 Relationships are associations between the entities.
 Attributes are properties which describe the entities.
Reading Materials 27

 Silberschatz, Korth and Sudharshan: Database System Concepts,

6th Edition, Mc-GrawHill, 2010
 C.J. Date, A Kannan, S. Swamynatham: An Introduction to
Database Systems, 8th Edition, Pearson Education, 2006
 Date, C.J., Introduction to Database Systems (7th Edition) Addison
Wesley, 2000
 https://www.tutorialspoint.com/dbms/er_diagram_representation.
htm