The Entity-Relationship Model

DEFINITION
The Entity-Relationship (ER) model was originally proposed by Peter in 1976
[Chen76] as a way to unify the network and relational database views. Simply
stated the ER model is a conceptual data model that views the real world as
entities and relationships. A basic component of the model is the Entity-
Relationship diagram which is used to visually represents data objects. Since Chen
wrote his paper the model has been extended and today it is commonly used for
database design For the database designer, the utility of the ER model is:

• it maps well to the relational model. The constructs used in the ER model
can easily be transformed into relational tables.
• it is simple and easy to understand with a minimum of training. Therefore,
the model can be used by the database designer to communicate the design to
the end user.
• In addition, the model can be used as a design plan by the database developer
to implement a data model in a specific database management software.

E-R Model concept

The ER data modeling techniques is based on the perception of a real world that
consists of a set of basic objects called entities, and of relationships among these
objects. In ER modeling, data is described as entities, relationships, and attributes.
In the following section, entities and attributes are discussed. Later, entity types,
their key attributes, relationship types, their structural constraints, and weak entity
types are discussed. In the last, we will apply ER modeling to our case study
problem "Library management system".

1
Entities and Attributes
One of the basic components of ER model is entity. An entity is any
distinguishable object about which information is stored. These objects can be
person, place, thing, event or a concept. Entities contain descriptive information.
Each entity is distinct.

An entity may be physical or abstract. A person, a book, car, house, employee etc.
are all physical entities whereas a company, job, or a university course, are
abstract entities.

Fig - Physical and Abstract Entity

Another classification of entities can be independent or dependent (strong or

weak) entity. Entities are classified as independent or dependent (in some
methodologies, the terms used are strong and weak, respectively). An independent
entity is one, which does not rely on another entity for identification. A dependent
entity is one that relies on another entity for identification. An independent entity
exists on its own whereas dependent entity exists on the existence of some other
entity. For example take an organization scenario. Here department is independent
entity. Department manager is a dependent entity. It exists for existing depts.
There won't be any department manager for which there is no dept.

Some entity types may not have any key attributes of their own. These are called
weak entity types. Entities belonging to a weak entity type are identified by being
related to specific entities from another entity type in combination with some of
their attribute values. For example, take the license entity. It can't exist unless it is
related to a person entity.

Entity sets:-

2
An entity is a “thing” or “object” in the real world that is distinguishable from all
other objects. An entity has a set of properties, and the values for some set of
properties may uniquely identify an entity. An entity is a concrete, such as a
person or a book, or it may be abstract, such as a loan, or a holiday, or a concept.
An entity set is a set of entities of the same type that share the same properties, or
attributes. The set of all persons who are customers at a given bank, for example,
can be defined as the entity set customer. Similarly, the entity set loan might
represent the set of all loans awarded by a particular bank. The individual entities
that constitute a set are said to be the extension of the entity set. A database
includes a collection of entity sets, each of which contains any number of entities
of the same type.

Figure : Entity type in ER diagram

Entity Types
An entity set is a set of entities of the same type that share the same properties, or
attributes. For example, all software engineers working in the department involved
in the Internet projects can be defined as the entity set InternetGroup. The
individual entities that constitute a set are called extension of the entity set. Thus,
all individual software engineers of in the Internet projects are the extensions of
the entity set InternetGroup.

Entity sets don’t need to be disjointed. For example, we can define an entity set
Employee. An employee may or may not be working on some Internet projects. In

3
InternetGroup we will have some entries that are there in Employee entity set.
Therefore, entity sets Employee and InternetGroup are not disjoint.

A database usually contains groups of entities that are similar. For example,
employees of a company share the same attributes. However, every employee
entity has its own values for each attribute. An entity type defines a set of entities
that have same attributes. A name and a list of attributes describe each entity type.

Fig. shows two entity types Employee and Product. Their attribute list is also
shown. A few members of each entity type are shown.

Fig. Two entity types and some of the member entities of each

An entity type is represented in ER diagrams as rectangular box and the

corresponding attributes are shown in ovals attached to the entity type by straight
lines. s

An entity type is basically the schema or intension or structure for the set of
entities that share the same structure whereas the individual entities of a particular
entity type are collectively called entity set. The entity set is also called the
extension of the entity type.

Attributes

4
After you identify an entity, then you describe it in real terms, or through its
attributes. Attributes are basically properties of entity. We can use attributes for
identifying and expressing entities. For example, Dept entity can have DeptName,
DeptId, and DeptManager as its attributes. A car entity can have modelno,
brandname, and color as its attributes.

A particular instance of an attribute is a value. For example, "Bhaskar" is one

value of the attribute Name. Employee number 8005 uniquely identifies an
employee in a company.

The value of one or more attributes can uniquely identify an entity.

Fig - Entity and its attributes

In the above figure, employee is the entity. EmpNo, Name, Designation and
Department are its attributes.

An entity set may have several attributes. Formally each entity can be described by
set of <attribute, data value> pairs.

Fig - Employee entity and its attribute values

Types of Attributes

5
Attributes can be of various types. In this section, we'll look at different types of
attributes. Attributes can be categorized as:

• Key or non key attributes

• Required or optional Attributes
• Simple or composite Attributes
• Single-valued and multi-valued Attributes
• Stored, Coded or derived Attributes

1. Key or non-key attributes

Attributes can be classified as identifiers or descriptors. Identifiers, more
commonly called keys or key attributes uniquely identify an instance of an entity.
If such an attribute doesn't exist naturally, a new attribute is defined for that
purpose, for example an ID number or code. A descriptor describes a non-unique
characteristic of an entity instance.

An entity usually has an attribute whose values are distinct for each individual
entity. This attribute uniquely identifies the individual entity. Such an attribute is
called a key attribute. For example, in the Employee entity type, EmpNo is the key
attribute since no two employees can have same employee number. Similarly, for
Product entity type, ProdId is the key attribute.

There may be a case when one single attribute is not sufficient to identify entities.
Then a combination of attributes can solve this purpose. We can form a group of
more than one attribute and use this combination as a key attribute. That is known
as a composite key attribute. When identifying attributes of entities, identifying
key attribute is very important.

2,Required or optional Attributes

An attribute can be required or optional. When it's required, we must have a value
for it, a value must be known for each entity occurrence. When it's optional, we
could have a value for it, a value may be known for each entity occurrence. For
example, there is an attribute EmpNo (for employee no.) of entity employee. This

6
is required attribute since here would be no employee having no employee no.
Employee's spouse is optional attribute because an employee may or may not have
a spouse.s

3.Simple and composite Attributes

Composite attributes can be divided into smaller subparts. These subparts
represent basic attributes with independent meanings of their own. For example,
take Name attributes. We can divide it into sub-parts like First_name,
Middle_name, and Last_name.

Attributes that can’t be divided into subparts are called Simple or Atomic
attributes. For example, EmployeeNumber is a simple attribute. Age of a person is
a simple attribute.

Composite Attributes

4. Single-valued and multi-valued Attributes

Attributes that can have single value at a particular instance of time are called
single valued. A person can’t have more than one age value. Therefore, age of a
person is a single-values attribute. A multi-valued attribute can have more than
one value at one time. For example, degree of a person is a multi-valued attribute
since a person can have more than one degree. Where appropriate, upper and
lower bounds may be placed on the number of values in a multi-valued attribute.

7
For example, a bank may limit the number of addresses recorded for a single
customer to two.

5. Stored, coded, or derived Attributes

There may be a case when two or more attributes values are related. Take the
example of age. Age of a person can be can be calculated from person’s date of
birth and present date. Difference between the two gives the value of age. In this
case, age is the derived attribute.

The attribute from which another attribute value is derived is called stored
attribute. In the above example, date of birth is the stored attribute. Take another
example, if we have to calculate the interest on some principal amount for a given
time, and for a particular rate of interest, we can simply use the interest formula.
Interest=NPR/100; In this case, interest is the derived attribute whereas principal
amount(P), time(N) and rate of interest(R) are all stored attributes.

8
Derived attributes are usually created by a formula or by a summary operation on
other attributes A coded value uses one or more letters or numbers to represent a
fact. For example, the value Gender might use the letters "M" and "F" as values
rather than "Male" and "Female".

The attributes reflect the need for the information they provide. In the analysis
meeting, the participants should list as many attributes as possible. Later they can
weed out those that are not applicable to the application, or those clients are not
prepared to spend the resources on to collect and maintain. The participants come
to an agreement, on which attributes belong with an entity, as well as which
attributes are required or optional.

Value Sets (domain) of Attributes

Each attribute of an entity type is associated with a value set. This value set
is also called domain. The domain of an attribute is the collection of all possible
values an attribute can have.

The value set specifies the set of values that may be assigned for each individual
entity. For example, we can specify the value set for designation attribute as
<“PM”, “Assit”, “DM”, “SE”>. We can specify “Name” attribute value set as
<strings of alphabetic characters separated by blank characters>. The domain of
Name is a character string.

9
Keys
There are 3 types of key used in E-R model
• Primary key
• Candidate key
• Foreign key

CANDIDATE KEYS
A candidate key is a set of one or more attributes which uniquely
distinguishes each instance of an entity. For example, a candidate
key for Employee may be Employee ID, candidate keys for
Budget may be Budget Year, Budget ID, or Effective Date.

Primary Key Identifier

The primary key of an entity unambiguously distinguishes
between occurrences of the entity. It is a unique identifier
comprised of one or more attributes of the entity. Each
occurrence of an entity has one value for its primary key. Select
the primary key from the list of candidate keys.
Each entity must be assigned a primary key. An entity can have
only one primary key.

Foreign Key Identifier

Foreign keys (also known as referential attributes) are attributes
that define relationships between entities. The attributes of a
foreign key in one entity are the attributes of a primary key in
another entity. For example, Department ID is the primary key of
Department and Department ID is a foreign key of Employee
defining the relationship "Employee works for Department."

10
Relationships
A Relationship represents an association between two or more entities. An
example of a relationship would be:

1. employees are assigned to projects

2. projects have subtasks
3. departments manage one or more projects

Relationships are classified in terms of degree, connectivity, cardinality,

and existence. These concepts will be discussed below.

Attributes of Relationship Types

 Relationships can have attributes similar to entity types.


 For example, in the relationship Works_On, between the Employee entity and
the Department entity we would like to keep track of the number of hours an
employee works on a project. Therefore we can include Number of Hours as an
attribute of the relationship
.
 Another example is for the “manages” relationship between employee and
department, we can add Start Date as an attribute of the Manages relationship.

 For some relationships (1:1, or 1:N), the attribute can be placed on one of the
participating entity types. For example the “Manages” relationship is 1:1,
StartDate can either be migrated to Employee or Department.

11
Classifying Relationships
Relationships are classified by their degree, connectivity, cardinality, direction,
type, and existence. Not all modeling methodologies use all these classifications.

Degree of an Entity Relationship

Relationships exhibit certain characteristics like degree, connectivity, and
cardinality. Once the relationships are identified their degree and cardinality are
also specified.

Degree: The degree of a relationship is the number of entities associated with

the relationship. The n-ary relationship is the general form for degree n. Special
cases are the binary, and ternary, where the degree is 2, and 3, respectively.

Unary (Recursive) relationship type is the relationship that involve only one entity
type. However, the same entity type participates in a relationship type in different
roles. For example, figure below shows the Supervise relationship type which
relates an Employee and a Supervisor who is also an employee. So in this
relationship, one employee has the role of supervisor, another has the role of
supervisee.

Figure : Supervise Relationship

12
In ER model, we have the diagram

Binary relationships, the association between two entities are the most
common type in the real world.

Fig shows a binary relationship between member and book entities of library
system

Fig. Binary Relationship

13
For example the “Joins in” relationship between EMPLOYEE and PROJECT

Figure : "Joins in" Relationship

The ER diagram for this relationship type is :

Figure : "Joins in" relationship notation

Non-binary Relationships

14
Non-binary relationships can easily be represented.

Figure shows an example.

Figure E-R diagram with a ternary relationship

This E-R diagram says that a customer may have several accounts, each located in
a specific bank branch, and that an account may belong to several different
customers.

A 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.

For example: The Supply relationship associates a SUPPLIER, a PART and a

PROJECT.

15
 Figure 13: Ternary relationship example

The ER diagram for this relationship type is:

Figure 14: Ternary relationship notation

 Direction

16
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.

 Type
An identifying relationship is one in which one of the child entities is also a
dependent entity. A non-identifying relationship is one in which both entities are
independent.

 Existence
Existence 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. An example of mandatory existence is the statement "every project
must be managed by a single department". If the instance of the entity is not
required, it is optional. An example of optional existence is the statement,
"employees may be assigned to work on projects".

Role Names and Recursive Relationships

17
 Each entity type in a relationship plays a particular role. The role name
specifies the role that a participating entity type plays in the relationship and
explains what the relationship means.
 For example, in the relationship between Employee and Department, the
Employee entity type plays the employee role, and the Department entity type
plays the department or employer role.
 In most cases the role names do not have to be specified, but in cases where the
same entity participates more than once in a relationship type in different roles.

For example, in the Company schema, each employee has a supervisor, we need to
include the relationship “Supervises”, however a supervisor is also an employee,
therefore the employee entity type participates twice in the relationship, once as an
employee and once as a supervisor, therefore we can specify two roles, employee
and supervisor

Constraints on Relationship Types

 Relationship types have certain constraints that limit the possible combination
of entities that may participate in relationship.

 An example of a constraint is that if we have the entities Doctor and Patient, the
organization may have a rule that a patient cannot be seen by more than one
doctor. This constraint needs to be described in the schema.

 There are two main types of relationship constraints, cardinality ratio, and
participation.

18
Strong entity:
Objects are represented by their attributes and , as objects are inter distinguishable,
a subset of these attributes forms a primary key for uniquely identified an instance
of entity .Entity types that have primary keys are called “STRONG ENTITIES”

Weak Entity Types

• Entity types that do not have key attributes are called weak entity types.
• Entities that belong 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.
• This entity type is called an identifying or owner entity type.
• The relationship that relates the identifying entity type with the weak entity
type is called an identifying relationship.
• A weak entity type always has a total participation constraint with respect to
the identifying relationship, because a weak entity cannot exist without its
owner.
• Not all existence dependencies result in a weak entity type; if an entity has a
key attribute then it is not a weak entity.
• A weak entity type usually has a partial key, which is the set of attributes that
can uniquely identify weak entities that are related to the same owner entity.

19
Weak Entity Example
Entity type DEPENDENT related to EMPLOYEE. This entity type is used to keep
track of the dependents of each employees via 1-N relationship. DEPENDENT
entity has Name, Birthdate and Relationship. Two dependents of two distinct
employees might have the same {Name, Birthdate, Relationship} values but they
are totally different. They are identified as distinct only after consider the
association with particular employee entities to which the dependents relates. So
the key of the DEPENDENT might be {EID, Name} in which EID is the attribute
from the strong entity type EMPLOYEE.

Figure 23: Weak entity type notation

20
Representation of Relationship Sets
Let R be a relationship set involving entity sets .

The table corresponding to the relationship set R has the following attributes:

If the relationship has k descriptive attributes, we add them too:

An example:

• The relationship set CustAcct involves the entity sets customer and account.
• Their respective primary keys are S.I.N. and account-number.
• CustAcct also has a descriptive attribute, date.
• This gives us the table of figure

Representation of Weak Entity Sets

For a weak entity set, we add columns to the table corresponding to the primary
key of the strong entity set on which the weak set is dependent.

For example, the weak entity set transaction has three attributes: transaction-
number, date and amount. The primary key of account (on which transaction
depends) is account-number.

21
Representation of Strong Entity Sets
We use a table with one column for each attribute of the set. Each row in the table
corresponds to one entity of the entity set. For the entity set account, see the table
of figure 2.14.

We can add, delete and modify rows (to reflect changes in the real world).

A row of a table will consist of an n-tuple where n is the number of attributes.

Actually, the table contains a subset of the set of all possible rows. We refer to the set of all
possible rows as the cartesian product of the sets of all attribute values.

We may denote this as

for the account table, where and denote the set of all account numbers and all account
balances, respectively.

In general, for a table of n columns, we may denote the cartesian product of by

22
Linking a Weak to a Strong Entity

These relationship sets are many-to-one, and have no descriptive attributes. The
primary key of the weak entity set is the primary key of the strong entity set it is
existence-dependent on, plus its discriminator.

The table for the relationship set would have the same attributes, and is thus
redundant.

Figure : E-R diagram with strong and weak entity sets

23
Min-Max Notation
• Before we saw that to specify structural constraints (cardinality) we used the
M:N notation.
• An alternate notation involves specifying a pair of integers, which are used to
specify the minimum and maximum participation of each entity type in the
form of (min, max)
• A minimum participation of 0 indicates partial participation (meaning that there
may be some entities that do not participate in the relationship)
• A minimum participation of 1 or more indicates total participation, meaning
that each entity must participate in exactly/at least one-relationship type.

The (min,max) notation

(0,1) (1,1)

(1,1) (1,N)

24
Relationship Type Constraints
The constraints of relationship types limit the possible combination of entities that
participate in the relationship set. Two main types of constraints is mapping
cardinality and participation

Mapping Cardinality

Mapping Cardinality describes the maximum number of entities that a given entity
can be associated with via a relationship. In this section, we consider only the
cardinality constraint for the binary relationship. The possible cardinality for
binary relationship types are : One - to- One (1-1) , One – to – Many (1 – N) and
Many – to – Many (M-N).

By connectivity we mean how many instances of one entity are associated with
how many instances of other entity in a relationship. Cardinality is used to specify
such connectivity. The connectivity of a relationship describes the mapping of
associated entity instances in the relationship. The values of connectivity are "one"
or "many". The 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-tomany.

A one-to-one (1:1) relationship is when at most one instance of an entity A

is associated with one instance of entity B. For example, take the relationship
between board members and offices, where each office is held by one member and
no member may hold more than one office.

25
Given two entity sets A and B, there is a one-to-one relationship between A and B
if each entity in the set A is associated with at most one entity in the set B and vice
versa each entity in the set B is associated with at most one entity in the set A.

Figure 15: One-to-one relationship

example

Example: An employee if is a manager then can manage one department and a

department can have only one manager.

Figure 16: One-to-one relationship notation

26
A one-to-many (1:N) relationship 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. An example of a 1:N relationships is a department has many employees;each

employee is assigned to one department.There is a one to many relationship sets
associates two entities sets A and B if each entity in A is associated with several
entities in B however, each entity in B is associated with at most one entity in A.

Figure 17: One-to-many relationship

example

Example: There are many employees work in a department however, an

employee can work for only one department.

Figure 18: One-to-many relationship notation

27
A many-to-many (M:N) relationship, sometimes called non-specific, 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. An example is employees may be assigned to no more than three projects at a
time; every project has at least two employees assigned to it.

There is a many to many relationship sets associates two entities sets A and B if
each entity in A is associated with several entities in B however, each entity in B is
associated with several entities in A.

Figure 19: Many-to-many relationship

example

Example: An employee can join in several projects and a project can have
several employees

Figure 20: Many-to-many relationship notation

28
Participation Constraints and Existence Dependencies

 The participation constraint specifies whether the existence of an entity depends on its
being related to another entity via the relationship type.
 The constraint specifies the minimum number of relationship instances that each entity can
participate in.
 There are two types of participation constraints:

o Total:
 If an entity can exist, only if it participates in at least one relationship instance,
then that is called total participation, meaning that every entity in one set,
must be related to at least one entity in a designated entity set.
 An example would be the Employee and Department relationship. If
company policy states that every employee must work for a department, then
an employee can exist only if it participates in at lest one relationship instance
(i.e. an employee can’t exist without a department)
 It is also sometimes called an existence dependency.
 Total participation is represented by a double line, going from the relationship
to the dependent entity.

o Partial:
 If only a part of the set of entities participate in a relationship, then it is called
partial participation.
 Using the Company example, every employee will not be a manager of a
department, so the participation of an employee in the “Manages” relationship
is partial.
 Partial participation is represented by a single line.

Relationship Review
a) Each time an attribute of one entity type refers to another entity type, some relationship
exists.
b) In ER diagrams, these references should be represented as relationships, rather than
attributes.
c) For example, in the Company database schema, an attribute of employee is the department
they work for, rather than representing this information as an attribute of the Employee
entity type, it should be represented on a diagram as a relationship between the two entities.

29
d) Relationships between entities are represented using a diamond shape.
e) Relationships are usually given a verb name, which specifies the relationship between two
entities.
f) If we look at the relationship between Employee and Department, an employee works for a
department, therefore the relationship would be represented

Works
Employee Department
for

30
Designing basic model and E-R Diagrams

E-R diagrams represent the schemas or the overall organization of the system. In
this section, we’ll apply the concepts of E-R modeling to our “Library
Management System” and draw its E-R diagram.

In order to begin constructing the basic model, the modeler must analyze the
information gathered during the requirement analysis for the purpose of: and

• classifying data objects as either entities or attributes,

• identifying and defining relationships between entities,
• naming and defining identified entities, attributes, and relationships,
• documenting this information in the data document.
• Finally draw its ER diagram.

To accomplish these goals the modeler must analyze narratives from users, notes
from meeting, policy and procedure documents, and, if lucky, design documents
from the current information system.

Reducing E-R Diagrams to Tables

A database conforming to an E-R diagram can be represented by a collection of

tables..For each entity set and relationship set, there is a unique table which is
assigned the name of the corresponding set. Each table has a number of columns
with unique names.

E-R diagrams constructs

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 academics texts and journals but rarely seen in either CASE tools or
publications by non-academics. Today, there are a number of notations used,
among the more common are Bachman, crow's foot, and IDEFIX.

31
All notational styles represent entities as rectangular boxes and relationships as
lines connecting boxes. Each style uses a special set of symbols to represent the
cardinality of a connection. The notation used in this document is from Martin.
The symbols used for the basic ER constructs are:

• entities are represented by labeled rectangles. The label is the name of the
entity. Entity names should be singular nouns.
• relationships are represented by a solid line connecting two entities. The
name of the relationship is written above the line. Relationship names should
be verbs.
• attributes, when included, are listed inside the entity rectangle. Attributes
which are identifiers are underlined. Attribute names should be singular
nouns.
• 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.

In E-R diagrams, entity types are represented by squares. See the table below.
Relationship types are shown in diamond shaped boxes attached to the
participating entity types with straight lines. Attributes are shown in ovals, and
each attribute is attached to its entity type or relationship type by a straight line.
Multivalued attributes are shown in double ovals. Key attributes have their names
underlined. Derived attributes are shown in dotted ovals.

Weak entity types are distinguished by being placed in double rectangles and by
having their identifying relationship placed in double diamonds.

Attaching a 1, M, or N on each participating edge specifies cardinality ratio of

each binary relationship type. The participation constraint is specified by a single
line for partial participation and by double lines for total participation. The
participation constraints specify whether the existence of an entity depends on its
being related to another entity via the relationship type. If every entity of an entity
set is related to some other entity set via a relationship type, then the participation
of the first entity type is total. If only few member of an entity type is related to
some entity type via a relationship type, the participation is partial.

32
 ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2
IN R
Cardinality Ratio 1:N FOR E1:E2 IN
R
Structural Constraint(Min,Max) On
Participation Of E In R

Naming Data Objects

The names should have the following properties:

 unique,
 have meaning to the end-user.
 contain the minimum number of words needed to uniquely and accurately
describe the object.

For entities and attributes, names are singular nouns while relationship names are
typically verbs.

33
Other Styles of E-R Diagram
The text uses one particular style of diagram. Many variations exist. Some of the variations
you will see are:

• Diamonds being omitted - a link between entities indicates a relationship.

o Less symbols, clearer picture.
o What happens with descriptive attributes?
o In this case, we have to create an intersection entity to possess the attributes.

• Numbers instead of arrowheads indicating cardinality.

o Symbols, 1, n and m used.
o E.g. 1 to 1, 1 to n, n to m.
o Easier to understand than arrowheads.
• A range of numbers indicating optionality of relationship. (See Elmasri & Navathe, p
58.)
o E.g (0,1) indicates minimum zero (optional), maximum 1.
o Can also use (0,n), (1,1) or (1,n).
o Typically used on near end of link - confusing at first, but gives more
information.
o E.g. entity 1 (0,1) -- (1,n) entity 2 indicates that entity 1 is related to between 0
and 1 occurrences of entity 2 (optional).
o Entity 2 is related to at least 1 and possibly many occurrences of entity 1
(mandatory).
• Multivalued attributes may be indicated in some manner.
o Means attribute can have more than one value.
o E.g. hobbies.
o Has to be normalized later on.

34
 Specialization:
An entity set may include sub-groupings of entities that are distinct
in some way from other entities in the set. For instance, a subset of entities
within an entity set may have attributes that are not shared by all the entities in
the entity set. The E-R model provides a means for representing these distinctive
entity groupings. Consider an entity set person, with attributes name, street and
city. A person may be further classified as one of the following (a) Customer (b)
Employee Each of these person types is described by a set of attributes that
includes all the attributes of entity set person plus possibly additional attributes.

For example, customer entities may be described further by the

attribute customer-id, whereas employee entities may be described further by the
attributes employee-id and salary. The process of designating sub-groupings
within an entity set is called specialization. The specialization of person allows
us to distinguish among persons according to whether they are employees or
customers.In terms of an E-R diagram, specialization is depicted by a triangle
component labeled ISA. The label ISA stands for “is a” and represents, for
example that a customer is a “person”. The ISA relationship may also be referred
to as a superclass-subclass relationship. Higher and lower-level entity sets are
depicted as regular entity sets-that is, as rectangles containing the name of the
entity set.

35
  Generalization:-

The refinement from an initial entity set into successive levels of entity sub-
groupings represents a top-down design process in which distinctions are made
explicit. The design process may also proceed in a bottom-up manner, in which
multiple entity sets are synthesized into a higher level entity set on the basis of
common features.

There are similarities between customer entity set and employee entity set in the
sense that they have several attributes in common. This commonality can be
expressed by generalization, which is a containment relationship that exists
between a higher-level entity set and one or more lower-level entity sets. In the
example, person is the higher level entity set and customer and employee are the
lower level entity set. Higher and lower level entity sets may also be designated by
the terms superclass and subclass, respectively. The person entity set is the
superclass of the customer and employee subclasses.

Generalization is the simple inversion of Specialization.

36
 Enhaced E-R model
Why EER?
The ER modeling concepts are not sufficient for representing new database
applications, which have more complex requirements than do the more
traditional applications.

Additional semantic data modeling concepts must be used to represent these

requirements as accurately and clearly as possible.

EER model concepts includes

All modeling concepts of basic ER

Additional concepts:
subclasses/superclasses
specialization/generalization
categories (UNION types)
attribute and relationship inheritance
These are fundamental to conceptual modeling
The additional EER concepts are used to model applications more completely and
more accurately
EER includes some object-oriented concepts, such as inheritance

37
Subclasses vs. Superclasses
The set of entities in each subclasses is a subset of the entities that belong to
EMPLOYEE
Each is called a subclass of EMPLOYEE
EMPLOYEE is the superclass for each of these subclasses
The relationship between a superclass and any one of its subclass is called a
superclass/subclass or class/subclass relationship.
e.g., EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are two
class/subclass relationships.

Properties of Superclasses and Subclasses

A member entity of the subclass represents the same real-world entity as some
member of the superclass.
The subclass member is the same as the entity in the superclass, but in a distinct
specific role.
When implementing a superclass/subclass relationship, a member of the subclass
may be represented as a distinct database object – a distinct record that is
related via the key attribute to its superclass entity.

Specialization
 The process of defining a set of subclass of an entity type (the superclass of
the specialization).
 The set of subclasses that form a specialization is defined on the basis of
some distinguishing characteristics of the entities in the superclass.
{SECRETARY, ENGINEER, TECHNICIAN} is a specialization of
EMPLOYEE based on the job type of each entity.
 The same entity type may have several specializations based on different
distinguishing characteristics.
 The EMPLOYEE entity type may have two specializations:

38
 – Based on the methods of pay:
{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}
– Based on the type of job:
{SECRETARY, ENGINEER, TECHNICIAN}
 A subclass can participate in specific relationship typ

The specialization process allows us to do the following:

 Define a set of subclass of an entity type
 Establish additional specific attributes with each subclass
 Establish additional specific relationship types between each subclass and
other entity types or other subclasses

39
E-R Diagram for library management system
In the library Management system, the following entities and attributes can be
identified.

• Book -the set all the books in the library. Each book has a Book-id, Title,
Author, Price, and Available (y or n) as its attributes.
• Member-the set all the library members. The member is described by the
attributes Member_id, Name, Street, City, Zip_code, Mem_type, Mem_date
(date of membership), Expiry_date.
• Publisher-the set of all the publishers of the books. Attributes of this entity
are Pub_id, Name, Street, City, and Zip_code.
• Supplier-the set of all the Suppliers of the books. Attributes of this entity are
Sup_id, Name, Street, City, and Zip_code.

Assumptions: a publisher publishes a book. Supplier supplies book to library.

Members borrow the book (only issue).

Return of book is not taken into account

40
Fig. 7.13 E-R Diagram of Library Management System.

41
 Bibliography:
 www.google.com
 www.wikipedia.com
 http://www.edrawsoft.com/datamodel.php

42