Entity-Relationship Model

 Entity-relationship model describes data

involved in real world in terms of objects
and their relationships.
 It is widely used for initial database
design.
 It describes overall structure of database.
 E-R model is in fact, semantic data model
which describes the meaning of data.
 It has a capability to map the meanings
and interactions of real world objects on
to the conceptual schema.
 Entities and Attributes:
 An entity is a thing in the real world with an
independent existence.
 An entity may be an object with a physical
existence (e.g. a particular person, car house
etc) or it may be an object with a conceptual
existence (e.g. a company, a job or a
university course etc.).
 Each entity has attributes.
 Attributes are the particular properties that
describe the entity.
 For example, an EMPLOYEE entity may be
described by the employee’s name, age,
address, salary and job.
 Types of Attributes:
 Several types of attributes occur in the ER model:
 Composite Versus Simple (Atomic) Attributes:
 Composite attributes can be divided into smaller subparts,
which represent more basic attributes with independent
meanings. For example, the address attribute of the
employee entity can be subdivided into stree_address, city
and state.
 Attributes that are not divisible are called simple or atomic
attributes. For example, the age attribute of the employee
entity.
 Single-valued Versus Multi-valued Attributes:
 Attribute that can take only one value for a particular
entity is called single-valued attribute. For example,
Roll_number attribute of STUDENT entity.
 Attribute that can take more than one value for a
particular entity is called multi-valued attribute. For
example, Phone_number attribute of a PERSON entity.
 Types of Attributes:
 Stored Versus Derived Attributes:
 An attribute that supplies a value to the related
attribute is called stored attribute.
 An attribute whose value is derived from a
stored attribute is called derived attribute.
 For example 'Date of birth' of a person is a
stored attribute. The value for the derived
attribute 'Age' can be derived by subtracting the
'Date of Birth' from the current date.
 Complex Attributes: A complex attribute
that is both composite and multi valued. For
example, if a person can have multiple
phones.
Entity Types and Entity Sets:
 An entity type defines a collection of entities that have the
same attributes.
 Each entity type in the database is described by its name
and attributes. For example, following figure shows two
entity types: EMPLOYEE and COMPANY.
 The collection of all entities of a particular entity type in
the database at any point in time is called an entity set. It
is also called the extension of the entity type.
Entity Types and Entity Sets:
 An entity type is represented in ER diagram as a
rectangular box enclosing the entity type name.
 Attributes names are enclosed in ovals and are
attached to their entity type by straight lines.
 Composite attributes are attached to their component
attributes by straight lines.
 Multi-valued attributes are displayed in double ovals.
 Following figure shows a CAR entity type in this
notation.
 Key attributes of an Entity Types:
 An entity type usually has an attribute whose values are
distinct for each individual entity in the entity set. Such
an attribute is called a key attribute, and its value can be
used to identity each entity uniquely.
 For example, the Name attribute is a key of the COMPANY
entity type because no two companies are allowed to
have the same name.
 Sometimes, several attributes together form a key, called
composite key.
 The uniqueness property of a key attribute must hold for
every entity set of the entity type.
 Hence, it is a constraint that prohibits any two entities
from having the same value for the key attribute at the
same time.
 Some entity types have more than one key attribute.
 An entity type may also have no key, in which case it is
called a weak entity type.
Value Sets (Domain) of attributes:
 Each simple attribute of an entity type is associated with a
value set (or domain of values), which specifies the set of
values that may be assigned to that attribute for each
individual entity.
 Value sets are typically specified using the basic data types
available in most programming languages, such as integer,
string, Boolean, float and so on.
 For example, if the range of ages allowed for employees is
between 16 and 70, we can specify the value set of the Age
attribute of EMPLOYEE to be the set of integer numbers
between 16 and 70.
 Value sets are not displayed in ER diagrams.
 Mathematically, an attribute A of entity type E whose value
set is V can be defined as a function from E to the power set
P (V) of V:
A:E → P (V)
 The power set P (V) of a set V is the set of all subsets of V.
 We refer to the value of attribute A for entity e as A (e).
Relationship Types, Sets and Instances:
 Whenever an attribute of one entity type refers to
another entity type, some relationship exists.
 For example, the attribute Manager of DEPARTMENT
refers to an employee who manages the department.
 A relationship type R among n entity types E1, E2,
…..En defines a set of associations (or a relationship
set) among entities from these entity types.
 Mathematically, the relationship set R is a set of
relationship instances ri, where each ri associates n
individual entities (e1, e2, …..en), and each entity ej in
ri is a member of entity type Ej, 1≤ j≤ n.
 Informally, each relationship instance ri in R is an
association of entities, where the association
includes exactly one entity from each participating
entity type.
 Relationship Types, Sets and
Instances:

 It associates each employee with the department for

which the employee works.
 In ER diagrams, relationship types are displayed as
diamond-shaped boxes, which are connected by straight
lines to the rectangular boxes representing the
participating entity types.
 Degree of a Relationship Type:
 The degree of a relationship type is the number of
participating entity types.
 In the below relationship, the WORKS_ON
relationship is of degree two.
 A relationship type of degree two is called binary,
and one of degree three is called ternary.
 Role Names and Recursive
Relationships:
 Each entity type that participates in a relationship
type plays a particular role in the relationship.
 For example, in the WORKS_ON relationship type,
EMPLOYEE plays the role of employee or worker and
DEPARTMENT plays the role of department or
employer.
 Technically, each participating entity type name can
be used as the role name.
 However, in some cases the same entity type
participates more than once in a relationship type in
different roles.
 When there is a relationship between two entities of
the same type, it is known as a recursive relationship.
 This means that the relationship is between different
instances of the same entity type.
 Role Names and Recursive
Relationships:
 Following figure shows an example.
Constraints on Relationship Types:
 Relationship types usually have certain
constraints that limit the possible
combinations of entities that may
participate in the corresponding
relationship set.
 These constraints are determined from
the real world situation that the
relationship represents.
 We can distinguish two main types of
relationship constraint:
 cardinality ratio and
 Participation constraint.
 Cardinality Ratio for Binary Relationships:
 The cardinality ratio for a binary relationship specifies the
maximum number of relationship instances that an entity can
participate in.
 The possible cardinality ratios for binary relationship types are
1:1, 1:N, N:1, and M:N.
 An example of a 1:1 binary relationship is shown in figure below:

 The MANAGES relationship relates a DEPARTMENT entity to

the EMPLOYEE who manages that department.
 Here, an employee can manage one department only and a
department can have one manager only.
 Cardinality Ratio for Binary
Relationships:
 The following relationship type WORKS_ON is of cardinality
ratio M:N because the rule is that an employee can work on
several projects and a project can have several employees.
 Participation Constraints:
 The participation constraint specifies whether the existence
of an entity depends on its being related to another entity via
the relationship type.
 This constraint specifies the minimum number of relationship
instances that each entity can participate in, and is
sometimes called the minimum cardinality constraint.
 There are two types of participation constraints-
 total and
 partial.
 If every employee must work for a department, then an
EMPLOYEE entity can exist only if it participates in at least
one WORKS_ON relationship instance. This type of
participation is called total participation.
 The participation of employee in the MANAGES relationship
type is partial because not every employee manage a
department.
 The cardinality ratio and participation constraint taken
together is called structural constraints of a relationship
type.
Attributes of Relationship Types:
 Relationship type can also have attributes similar to those of
entity types. For example, to record the number of hours per
week an employee works on a particular project, we can include
an attribute Hours for the WORKS_ON relationship type.
 The attribute of 1:1 relationship type can be migrated to one of
the participating entity types. For example, the Start_Date
attribute for the MANAGES relationship can be an attribute of
either EMPLOYEE or DEPARTMENT.
 For a 1 : N relationship type, a relationship attribute can be
migrated only to the entity type on the N-side of the relationship.
For example, if the WORKS_ON relationship has an attribute
Start_Date, this attribute can be included as an attribute of
EMPLOYEE.
 For M : N relationship types, some attributes may be determined
by the combination of participating entities in a relationship
instance, not by any single entity. Such attributes must be
specified as relationship attributes. For example, the Hours
attribute of the M:N relationship WORKS_ON, the number of hours
an employee works on a project is determined by an employee-
project combination and not separately by either entity.
 Weak Entity Types:
 Entity types that do not have key attributes of their own
are called weak entity types.
 In contrast, regular entity types that do have a key
attribute are called strong entity types.
 Entities belonging to a weak entity type are identified
by being related to specific entities from another entity
type in combination with one of their attribute values.
We call this other entity type the identifying or owner
entity type.
 The relationship type that relates a weak entity type to
its owner is called the identifying relationship of the
weak entity.
 The identifying entity type is also sometimes called the
parent entity type or the dominant entity type.
 The weak entity type is also sometimes called the child
entity type or the subordinate entity type.
 Weak Entity Types:
 A weak entity type always has a total participation constraint
with respect to its identifying relationship because a weak
entity cannot be identified without an owner entity. For
example, the entity type DEPENDENT is used to keep the
track of the dependents of each employee via a 1: N
relationship. Two dependents of two distinct employees may
have the same values for Name, Birth_Date, Sex and
Relationship, but they are still distinct entities. They are
identified as distinct entities only after determining the
particular employee entity to which each dependent is
related.
 A weak entity type normally has a partial key, which is the
set of attributes that can uniquely identify weak entities that
are related to the same owner entity. For example, if we
assume that no two dependents of the same employee ever
have the same first name, the attribute Name of the
DEPENDENT is the partial key.
 Partial key is sometimes called the discriminator.
 Weak Entity Types:
 In ER diagrams, both a weak entity type and its identifying
relationship are distinguished by surrounding their boxes and
diamonds with double lines. The partial key attribute is underlined
with a dashed or dotted line as shown in figure below:
Summary of the ER Diagram Notations
 Subclasses and Super classes:
 An entity type has numerous sub-groupings of its
entities that are meaningful and need to be
represented explicitly because of their significance to
the database applications.
 For example, the entities that are members of the
EMPLOYEE entity type may be grouped further into
SECRETARY, ENGINEER, and MANAGER and so on.
 The set of entities in each of the later groupings is a
subset of the entities that belong to the EMPLOYEE
entity set; meaning that every entity that is a
member of one of these sub-groupings is an
employee.
 We call each of these sub-groupings a subclass of the
EMPLOYEE entity type, and the EMPLOYEE entity type
is called the super class for each of these subclasses.
 Subclasses and Super classes:
 Figure below shows how to represent these
concepts diagrammatically in EER diagrams.
 Specialization and Generalization:
 Specialization is the process of defining a set of subclasses of an
entity type; this entity type is called the superclass of the
specialization.
 The set of subclasses that forms a specialization is defined on
the basis of some distinguishing characteristics of the entities in
the superclass. For example, the set of subclasses {SECRETARY,
ENGINEER, TECHNICIAN} is a specialization of the superclass
EMPLOYEE that distinguishes among employee entities based on
the job type of each employee entity.
 Figure above shows how we represent a specialization
diagrammatically in an EER diagram.
 The subclasses that define a specialization are attached by lines
to a circle that represents the specialization, which is connected
to the superclass.
 The subset symbol on each line connecting a subclass to the
circle indicates the direction of the superclass/subclass
relationship.
 Attributes that apply to entities of a particular subclass are
attached to the rectangle representing that subclass. These are
called specific attributes (or local attributes) of the subclass.
 Why Specialization?
 There are two main reasons for including
class/subclass relationships and specialization in a
data model:
 The first is that certain attributes may apply to some but
not all entities of the superclass. A subclass is defined to
group the entities to which these attributes apply.
 The second reason for using subclass is that some
relationship types may be participated in only by entities
that are members of the subclass.
 In summary, the specialization process allows us to
do the following:
 Define a set of subclasses of an entity type.
 Establish additional specific attributes with each subclass.
 Establish additional specific relationship types between
each subclass and other entity types of other subclasses.
 Generalization:
 It is the reverse process of abstraction in which we suppress the differences among several
entity types, identify their common features, and generalize them into a single superclass of
which the original entity types are special subclasses.
 For example, consider the entity types CAR and TRUCK shown in figure (a) below:

 Because they have several common attributes, they can be generalized into the entity type
VEHICLE, as shown in figure (b) above. Both CAR and TRUCK are now subclasses of the
generalized superclass VEHICLE.
 The term generalization is used to refer to the process of defining a generalized entity type
from the given entity types. It can be viewed as the inverse of specialization process.
Constraints on Specialization & Generalization:
 In general, we may have several specializations defined on the same entity
type. In such a case, entities may belong to subclasses in each of the
specializations.
 However, a specialization may also consist of a single subclass only. In such
a case, we do not use the circle notation.
 In some specializations, we can determine exactly the entities that will
become members of each subclass by placing a condition on the value of
some attribute of the superclass. Such subclasses are called predicate-
defined (or condition-defined) subclasses.
 For example, if the EMPLOYEE entity type has an attribute job-type, we can
specify the condition of membership in the SECRETARY subclass by the
condition (job-type=’Secretary’), as shown in figure below:
Constraints on Specialization & Generalization:
 The condition is called the defining predicate of the subclass. It is
a constraint specifying that exactly those entities of the
EMPLOYEE entity type whose attribute values for job-type is
‘Secretary’ belong to the subclass.
 We display a predicate-defined subclass by writing the predicate
condition next to the line that connects the subclass to the
specialization circle.
 If all subclasses in a specialization have their membership
condition on the same attribute of the superclass, the
specialization itself is called an attribute-defined specialization,
and the attribute is called the defining attribute of the
specialization.
 When we do not have a condition for determining membership in
a subclass, the subclass is called user-defined.
 Two other constraints that may apply to a specialization are
disjointness constraints and completeness constraints.
 A specialization that is attribute-defined implies the disjointness
constraint if the attribute used to define the membership
predicate is single valued.
 Figure above illustrates this case, where the d in the circle stands
for disjoint.
Constraints on Specialization & Generalization:
 If the subclasses are not constrained to be disjoint, their sets of
entities may overlap, that is, the same entity may be a member of
more than one subclass of the specialization. This case is
displayed by placing an O in the circle as shown in figure below:

 The completeness constraint may be total or partial.

 A total specialization constraint specifies that every entity in the
superclass must be a member of at least one subclass in the
specialization. This is shown in EER diagram by using a double
line to connect the superclass to the circle.
 A single line is used to display a partial specialization which allows
an entity not to belong to any of the subclasses.
The End