LESSON

2
DATABASE DESIGN AND ER DIAGRAMS

CONTENTS
2.0 Aims and Objectives
2.1 Introduction
2.2 Database design
2.3 Entity, Attributes and Entity Sets
2.4 Relationships and Relationship Set
2.5 E-R Diagrams
2.6 Additional Features of ER Diagrams
2.7 Conceptual Database Design with the ER Model
2.8 Let us Sum up
2.9 Lesson end Activities
2.10 Keywords
2.11 Questions for Discussion
2.12 Suggested Readings

2.0 AIMS AND OBJECTIVES

At the conclusion of this lesson you should be able to:
l Explain the designing of physical components of a database
l Identify entities, attributes and relationships in a given data management situation
l Draw ER diagrams for a given entity-relationship scenario
l Design database using ER diagrams

2.1 INTRODUCTION
Constructing a database to manage a data application requires a lot of intuition and
experience. An ill-designed database can render the entire effort put into the development
of a database system useless. The database development itself concerns with identifying
the items for which data needs to be stored and subsequently organizing the data into a
useful form suitable for data management. This lesson revolves around the means and
tools used in the database development activity.

2.2 DATABASE DESIGN

A DBMS is required to manage data of an enterprise. A DBMS itself does not come
with the enterprise data. The database designer has to decide and construct that database,
Relational Database its structure and the data itself. The effort usually begins with the identification of the
Management System
data items that are required to be stored in the database. This is often done with the help
of data modeling tools.
A data model is a collection of concepts that can be used to describe the structure of a
database and provides the necessary means to achieve this abstraction whereas structure
of a database means the data types, data semantics, relationships and constraints that
should hold on the data. Database designing is essentially a modeling activity which
maps the miniworld of the enterprise to database components.
Various data models have been proposed. They fall into three different groups:
l Object based logical models
l Record-based logical models
l Physical models
Each data model serves individual database designing purposes. Object-Based Logical
Models are used in describing data at the logical and view levels. They are characterized
by the fact that they provide fairly flexible structuring capabilities and allow data constraints
to be specified explicitly. There are many different models and more are likely to come.
Several of the more widely known ones are:
l The Entity-Relationship model
l The object-oriented model
l The semantic data model
l The functional data model
The Entity-Relationship (E-R) data model is based on a perception of a real world that consists
of a collection of basic objects, called entities, and of relationships among these objects.
The object-oriented model looks upon the world in terms of discrete objects each
possessing identifying characteristics and a set of behaviors. The objects are taken to be
capable of mutual interaction through message passing.
In contrast to the above two models, semantic data models intend to capture the meaning
of data in its structure.
On the other hand the functional data models are based on the presumption that the
world is made up of functional units. Each entity of the miniworld is identified with the
function it performs.
We will discuss Entity-Relationship models in this lesson. The building blocks of E-R
modeling are discussed first.

2.3 ENTITY, ATTRIBUTES AND ENTITY SETS

E-R models are formed using entity, attributes and relationships.

Entity
Entity is an item - person or thing - that can be identified in the miniworld under
consideration. For instance, while analyzing a banking system, we come across several
entities such as Account holder, Branch manager, Account books, Cheque books and the
like. Each of these identifiable things are entities as far as banking miniworld is concerned.

Attribute
An attribute is a characteristic property of an entity. Each entity of the system under
44 consideration has a number of different attributes highlighting different aspect of the
entity. Thus, Name, Address, Date of birth, Date of opening account etc.; and Name, Database Design
and ER Diagrams
Address, Employee number, Date of joining etc.; are a few attributes of the Account
holder and Branch manager entities respectively. Similarly, Account number, Branch
code, etc. are a few attributes of the cheque book entity.
An entity is represented by the set of attributes it has. Every entity is described by a set
of (attribute, data value) pair. Thus, the Account holder and Branch manager entities can
be represented as follows:
AccountHolder(Name="Eknath", Address="A-45, Tagore Garden", DateOfBirth="13/11/1966",
DateOfOpeningAccount="12/10/2005")
BranchManager(Name="Vibhor Kasliwal", Address="B-46, Naraina", EmployeeNumber="BM008",
DateOfJoining="01/07/2006")

An attribute may be restricted to take values from a set of values called domain of the attribute.
Attributes can be classified in a number of different ways. According to atomicity an attribute
can be Simple or Composite. A simple attribute is atomic and cannot be broken further down
into simpler components where as a composite attribute is composed of simpler values. For
instance, while age is a simple attribute of a student entity, date of birth is a composite
attribute because it can be still broken into three simpler values - day, month and year.
On the basis of whether an attribute must take a value for an instance of a given entity
or not, attributes can be either Null-valued or Non-Null-valued. A null attribute may not
take a value in which case it is said to have missing value. A non-null attribute must not
have missing value. Note that missing value is not same as zero. Thus, the PhoneNumber
attribute is a null-valued because an entity may or may not have a phone number. Attributes
which are not null type must not accept a missing value.
On the basis of the multiplicity of values taken attributes can be classified either as Single-
valued or Multi-valued. A single-valued attribute takes only one value for a given entity
while a multi-valued attribute can take more than one value for a given entity. For instance,
for the ongoing banking system, the attribute BranchManagerId is a single-valued while
PhoneNumber is a multi-valued attribute - i.e., one instance of a branch manager will have
a single value for BranchManagerId but can have more than one phone number.
An attribute can be Derivable or Non-Derivable. Derivable attribute can be obtained by
subjecting other attributes to computation. For instance, Age is a derived attribute for an
AccountHolder entity because its value can be obtained by computing the difference between
the current date and the DateOfBirth attribute. Obviously, since the value of the derived
attribute can be computed from other attributes its value need not be stored in the database.

Entity Set
A collection of entities of the same type is referred to as entity set.

E = {x x is anentity}

Entity sets may or may not be disjoint to each other. For example, the entity set
BrabchManagers of all branch managers and the entity set AccountHolders of all account
holders of a particular bank may have common members and therefore are not disjoint.
An attribute acts like a function mapping a set of entity into a domain of attributes.
atribute
entity æææ Æ domain
There is one pair for each attribute of the entity set. An entity also corresponds to a data
type (such as structure) of a computer programming language. Thus, a programming
language variable corresponds to an entity in the E-R model.

45
Relational Database
Management System 2.4 RELATIONSHIPS AND RELATIONSHIP SET
Entities do not exist in isolation form each other. They are more often than not related
somehow with each other. A relationship is an association between entities. Let there be
n number of entities given by:
E1,E2,E3 , , ,….,En

A relationship is defined as a collection of attributes (r1,r2,r3,....rn) such that r1 ΠE1 and

and so on. A relationship set is a set of relationships of the same type.
For instance, consider the two entity sets - AccountHolders and Account. These two
entities are related to each other because an Account is owned by an Account holder.
We can give a name to this relationship - say, Owns. The relationship would read as:
AccountHolder(Name="Eknath", Address="A-45, Tagore Garden", DateOfBirth="13/11/1966",
DateOfOpeningAccount="12/10/2005") Owns Account (AccountNumber = "1345",
OpeningBalance=50000)

In fact another relationship may also exist in the opposite manner. In our case the
relationship - Belongs To - can be thought of a relationship from Account entity to
AccountHolder entity as:
Account (AccountNumber = "1345", OpeningBalance=50000) Belongs To AccountHolder(Name="Eknath",
Address="A-45, Tagore Garden", DateOfBirth="13/11/1966", DateOfOpeningAccount="12/10/2005")

Thus, the two relationships "Owns" and "Belongs To" are inversely related to each other.
A relationship that exists between two entities is called binary relationship. But a
relationship may exist between more than two entities as well. A relationship between
three entity sets is called ternary relationship, and so on. The number of sets forming a
relationship is known as degree of relationship. Therefore, a binary relationship is of
degree 2 while ternary is that of 3 and a quinary of degree 5.
The objective of the E-R designing activity is to obtain these components of the E-R model.

Check Your Progress

Define the following:

(i) The entity-relationship model
(ii) Relationship and Relationship set
...........................................................................................................................
...........................................................................................................................
...........................................................................................................................
...........................................................................................................................
...........................................................................................................................

2.5 E-R DIAGRAMS

E-R diagrams are very useful tools to develop and describe the E-R model of a database.
In its original form ER diagrams were proposed by Dr. Pin-Shan Chen in the year 1976.
The popularity of the tools caused many variants come up since then.
E-R diagrams are composed of symbolic notations for entities, attributes and relationships
along with other aspects of these. A few of the symbolic notations and their meaning are
46 listed in the Table 2.1.
 Table 2.1: Symbols and their meaning used in ER-diagrams Database Design
and ER Diagrams
Symbol Meaning

Entity

Single-valued
attribute

Relationship

Connector

Derived attribute

Multi-valued attribute

Existence
dependency

Identifying
relationship

This list is not complete. Other symbols will be coved later. Using these symbols one can
draw an entity-relationship diagram for a database. ER diagram for the entity
AccountHolder is shown in figure 2.1 and for entity Account is shown in figure 2.2

Figure 2.1: ER diagram for the entity: Account Holder (Name, Address, Date of Birth, Date of
Opening Account)

Figure 2.2: ER diagram for the entity: Account (Account Number, Opening Balance) 47
Relational Database
Management System

Figure 2.3: ER diagram the relationship “Owns”

Cardinality Constraints
Constraints are domain rules that must be followed by the ER components for which
they are defined. A common constraint laid on relationship is that of cardinality. Cardinality
constraint specifies the multiplicity of instances of entities related to each other by a
relationship.
The relationship between entity sets may be many-to-many (M: N), one-to-many (1:M),
many-to-one (M: 1) or one-to-one (1:1). The 1:1 relationship between entity sets E1 and
E2 indicates that for each entity in either set there is at most one entity in the second set
that is associated with it. The 1:M relationship from entity set E1 to E2 indicates that for
an occurrence of the entity from the set E1, there could be zero, one, or more entities
from the entity set E2 associated with it. Each entity in E2 is associated with at most one
entity in the entity set E1. In the M: N relationship between entity sets E1 and E2, there
is no restriction to the number of entities in one set associated with an entity in the other
set. The database structure, employing the E-R model is usually shown pictorially using
entity-relationship (E-R) diagram. The cardinality of a relation may be represented by a
set of pictorial notations called Crow Feet notation shown listed in table 2. These symbols
are paired to form desired cardinality.
Table 2.2.: Crow feet notation

Crow Feet Notation Meaning

0 Zero

1 Exactly one

M Many

Paired Notation

Paired Symbol Meaning

0/1 Zeor or one

0/M Zero or one to zero or one

1/M Zero or one to exactly one

The "Crow's Foot" notation represents relationships with connecting lines between entities,
and pairs of symbols at the ends of those lines to represent the cardinality of the
relationship.
To illustrate these different types of relationships consider the following entity sets:
DEPARTMENT, MANAGER, EMPLOYEE, and PROJECT.
The relationship between a DEPARTMENT and a MANAGER is usually one-to-one;
48 there is only one manager per department and a manager manages only one department.
This relationship between entities is shown in Figure 2.4. Each entity is represented by a Database Design
and ER Diagrams
rectangle and the relationship between them is indicated by a direct line. The relationship
for MANAGER to DEPARTMENT and from DEPARTMENT to MANAGER is both
1:1. Note that a one-to-one relationship between two entity sets does not imply that for
an occurrence of an entity from one set at any time there must be an occurrence of an
entity in the other set. In the case of an organization, there could be times when a
department is without a manager or when an employee who is classified as a manager
may be without a department to manage. Figure 2.5 shows some instances of one-to-
one relationships between the entities DEPARTMENT and MANAGER.

Figure 2.4: One-to-one Relationship

Figure 2.5: An instance of One-to-One Relationship

Following are the examples of the same relationship under different cardinality constraints
(figure 2.6 to 2.11).

Figure 2.6: A Department is managed by no Manager

Figure 2.7: One Department is managed by exactly one Manager

Figure 2.8: One Department is managed by many Managers

Figure 2.9: One Department is managed by one or more Managers

Figure 2.10: A Deparment has none or exactly one Manager

Figure 2.11: A Department has none or many Managers

A one-to-many relationship exists from the entity MANAGER to the entity EMPLOYEE
because there are several employees reporting to the manager. As we just pointed out,
there could be an occurrence of the entity type MANAGER having zero occurrences of
the entity type EMPLOYEE reporting to him or her. A reverse relationship, from
EMPLOYEE to MANAGER, would be many to one, since many employees may be
supervised by a single manager. However, given an instance of the entity set EMPLOYEE,
there could be only one instance of the entity set MANAGER to whom that employee
49
Relational Database reports (assuming that no employee reports to more than one manager). The relationship
Management System
between entities is illustrated in Figure 2.12 to 2.13.

Figure 2.12: (M:1) Manay Employees Report to one Manager

Figure 2.13: An instance of (M:1) Relation

The relationship between the entity EMPLOYEE and the entity PROJECT can be derived
as follows: Each employee could be involved in a number of different projects, and a
number of employees could be working on a given project. This relationship between
EMPLOYEE and PROJECT is many-to-many. It is illustrated in Figure 2.14 to 2.15.

Figure 2.14: (M:N) Many Employees Report to Many Managers

Figure 2.15: An instance of (M:N) Relationship

Key Constraints
A key is a value (or set of values) that can serve the purpose of identifying instances at
various occasions is called a key. As mentioned earlier entities and relationships can
have attributes. Also each entity and relationship can have many instances.
An attribute (or a set of attributes) that tells each instance from the other is called
primary key. It is not necessary that the primary key is unique itself. An entity (or
relationship) may have more than one primary key. One of these possibilities is designated
to be primary key the rest are referred to as candidate keys. A set of attributes containing
a primary key is called a superkey.
In an ER diagram a primary key is indicated by underlining the key attribute(s). For
instance in our banking example, AccountNumber attribute can be taken as the primary
key for the Account entity because this attribute (AccountNumber) is capable of identifying
each instance of Account entity uniquely. The same is indicated by underlining the attribute
in the ER diagram (Figure 2.16).

Figure 2.16: Primary key for Account entity

50
However, for our AccountHolder entity none of the attributes can individually identify Database Design
and ER Diagrams
the instances uniquely as there can be many AccountHolders with same name. Similarly,
date of birth may not be unique for each AccounHolder. In this case we can take the set
of all attributes to be the primary key for AccountHolder entity. We are assuming here
that no two AccountHolders have same name, same address, same date of birth and
opened their accounts the same day. A reasonable assumption! The ER diagram is shown
in the figure 2.17.

Figure 2.17: Primary key for Account Holder entity

Like entities relationships can also have attributes and hence a primary key. However,
for those relationships not having any associated attribute the union of the primary keys
of all the participating entities may be taken as its primary key.
A primary key may not exist for an entity. Sometimes an entity may not have sufficient
number of attributes to form a primary key. Such entities are called weak entity and
those having their own primary keys are called strong entity. Weak entities can be identified
uniquely with the help of another entity called owner entity. The primary key for a weak
entity is formed using the primary key of owner entity and an attribute from the weak
entity. The attribute of weak entity taken into its primary key is called discriminator of
the weak entity. For instance, consider the entity - receipt - having following attributes.
Receipt(ReceiptNo, ReceiptDate, ReceiptAmount)
Two receipts cannot be set apart by using these attributes since many receipts may have
same set of these attributes. Therefore, this is a weak entity. However, if it is combined
with an account number it may become identifiable through a relationship. Hence, Account
entity may be taken as owner entity for receipt entity. The primary key of receipt entity
will then be:
(AccountNumber, ReceiptNo)
Here, attribute ReceiptNo is the discriminator of the weak entity receipt.
In ER diagram a weak entity is indicated by a double rectangle and the usual rectangle
is reserved for strong entity and dashed underline indicates the discriminator attribute.
Thus, the ER diagram for these entities is shown in figure 2.18.

Figure 2.18: Weak entity

51
Relational Database The ownership relationship that combines a weak entity with a strong entity is called
Management System
identifying relationship. Here, in our case, Account_Receipt is the identifying relationship
that combines the weak entity - Receipt - with a strong owner entity - Account. The
double connector indicates that a receipt exists only when a corresponding account
exists. The arrow indicates the fact that each receipt is meant for a single account.

2.6 ADDITIONAL FEATURES OF ER DIAGRAMS

Apart from the essential features discussed earlier entity-relationship diagrams also capture
some specialized features of the model. We will discuss two of them here - a)
generalization and specification, and b) aggregation.

Generalization and Specification

Abstraction is the simplification mechanism used to hide superfluous details of a set of
objects, it allows one to concentrate on the properties that are of interest to the application.
As such, car is an abstraction of a personal transportation vehicle but does not reveal
details about model, color, and so on. Vehicle itself is an abstraction that includes the
types car, truck, and bus.
There are two main abstraction mechanisms used to model information: Generalization
and aggregation. Generalization is the abstracting process of viewing set of objects as a
single general class by concentrating on the general characteristics of the constituent
sets while suppressing or ignoring their differences. It is the union of a number of lower-
level entity types for the purpose of producing a higher-level entity type. For instance,
student is a generalization of graduate or undergraduate, full-time or part-time students.
Similarly, employee is a generalization of the classes of objects cook, waiter, and cashier.
Generalization is an IS_A relationship; therefore, manager IS_An employee, cook IS_An
employee, waiter IS_An employee, and so forth. Specialization is the abstracting process
of introducing new characteristics to an existing class of objects to create one or more
new classes of objects. This involves taking a higher-lever, and using additional
characteristics, generating lower-level entities. The lower-level entities also inherit the,
characteristics of the higher-level entity. In applying the characteristic size to car we can
create a full-size, mid-size, compact, or subcompact car. Specialization may be seen as
the reverse process of generalization: additional specific properties are introduced at a
lower level in a hierarchy of objects. Both processes are illustrated in the Figure 1.18
wherein the lower levels of the hierarchy are disjoint.
The entity set EMPLOYEE is a generalization of the entity sets
FULL__TIME_EMPLOYEE and PART_TIME_EMPLOYEE. The former is a
generalization of the entity sets faculty and staff; the latter, that of the entity sets
TEACHING and CASUAL_FACULTY and STAFF inherit the attribute Salary of the
entity set FULL_TIME_EMPLOYEE and the latter, in turn, inherits the attributes of
EMPLOYEE. FULL_TIME_EMPLOYEE is a specialization of the entity set
EMPLOYEE and is differentiated by the additional attribute Salary. Similarly,
PART_TIME_EMPLOYEE is specialization differentiated by the presence of the attribute
Type.
In designing a database to model a segment of the real world, the data-modeling scheme
must be able to represent generalization. It allows the model to represent generic entities
and treat a class of objects and specifying relationships in which the generic objects
participate.
Generalization forms a hierarchy of entities and can be represented by a hierarchy of
tables, which can also be shown through following relations for conveniences.
EMPLOYEE (Empl_No, Name, Date_of_birth)
52
FULL_TIME_EMPLOYEE (Empl_No, Salary)
PART_TIME_EMPLOYEE (Empl_No, Type) Database Design
and ER Diagrams
FACULTY (Empl_No, Degree, Interest)
STAFF (Empl_No, Hour_rate)
TEACHING (Empl_No, Stipend)

E m p loy e e _ N o D a te _ o f_ H ire
Nam e

EM PLOY EE

G E N E R A L IZ AT IO N S P E C IA L IZ AT IO N

IS _ A IS _ A

F U L L _ T IM E _ PA R T _ T IM E _
S a la r y EM PLOY EE Ty p e
EM PLOY EE

IS _ A IS _ A IS _ A IS _ A

fa c u lty S ta ff te a ch in g casual

D e g re e In te re s t C la ss ific a tio n S tip e n d H o u r_ R a te

Figure 2.19: Generalization and Specialization

Here the primary key of each entity corresponds to entries in different tables and directs
one to the appropriate row of related tables.
Another method of representing a generalization hierarchy is to have the lowest-level
entities inherit the attributes of the entities of higher levels. The top and intermediate-
level entities are not included as only those of the lowest level are represented in tabular
form. For instance, the attributes of the entity set FACULTY would be [Empl_No, Name,
Date_of_Hire, Salary, Degree, Interest). A separate table would be required for each
lowest-level entity in the hierarchy. The number of different tables required to represent
these entities would be equal to the number of entities at the lowest level of the
generalization hierarchy.

Aggregation
Aggregation is the process of compiling information on an object, thereby abstracting a
higher-level object. In this manner, the entity person is derived by aggregating the
characteristics name, address, and IDnumber. Another form of the aggregation is
abstracting a relationship between objects and viewing the relationship as an object. As
such, the ENROLMENT relationship between entities Student and Course could be
viewed as entity REGISTRATION. Examples of aggregation are shown in Figure 2.20

53
Relational Database
Management System Person

Name Address ID number

(a)

Student Emrolment Course

(b)
Figure 2.20: Example of Aggregation

Accounting Code Limits

Student Computing Course

Computing System

Figure 2.21: A Relationship Among Three Entities

Consider the relationship COMPUTING of Figure 2.21. Here we have a relationship

among the entities STUDENT, COURSE, and COMPUTING SYSTEM. A student
registered in a given course uses one of several computing systems to complete assignments
and projects. The relationship between the entities STUDENT and COURSE could be
the aggregated entity REGISTRATION as discussed above. Another method of
aggregating is to consider a relationship consisting of the entity COMPUTING SYSTEMS
being assigned to Courses. This relationship can be aggregated as a new entity and a
relationship established between it and STUDENT. Note that the difference between a
relationship involving an aggregation and one with the three entities lies in the number of
relationship involving an aggregation and one with the three entities lies in the number of
relationships. In the former case we have two relationships; in the latter, only one exists.
The approach to be taken depends on what we want to express. We would use the
ternary relationship related to a COMPUTING SYSTEM.
ER CASE Tools
As with many other things even ER diagramming has been automated. There is no
dearth of software tools - called data modelers - that help designers create, manipulate
and analyze ER diagrams. A few of them are mentioned below.
ConceptDraw Enterprise Architect
ER/Studio Microsoft Visio
OmniGraffle Oracle Designer

54
PowerDesigner Rational Rose
 Database Design
2.7 CONCEPTUAL DATABASE DESIGN WITH THE ER and ER Diagrams
MODEL
Database designing is a long arduous process that becomes even more complex for
complex user requirements. The process encompasses all that takes to fit a database
solution to the users' requirements. Generally, users' requirements are not captured
correctly because either the user is unable to specify his requirements clearly or the
developer comprehends differently. Therefore, usually database design process is carried
out in iterative manner. In any case the database design process goes through the following
broad developmental phases:
Conceptual design: In this phase data models are developed independent of any physical
considerations.
Logical design: In this phase the conceptual design is refined and the same is mapped
onto some database model. The database models to choose from are relational model,
object-oriented model, network model, hierarchical model etc.
Physical design: in this phase the logical model obtained thus far is mapped onto a
specific Database Management System. Here one has a lot any choices ranging from
simple MS-Access to massive Oracle.
Note that in some cases where good understanding of the domain data is available
upfront some of these phases may be skipped and tables and other objects can be created
right away in a specific database management system. However, the real world situation
happens to be far more complex than that. Therefore, for real world applications, one is
advised to use all the three phases of development. This will ensure that the database
has been designed to operate as desired.
Conceptual design is an activity of domain data modelling wherein we identify the data
objects or entities and their relationships are identified and documented. ER diagrams
are extremely helpful in arriving at the conceptual design of a database. Separate ER
diagrams of entities and relationships are laid down to form the complete conceptual
design.

2.8 LET US SUM UP

l A data model is a collection of concepts that can be used to describe the structure
of a database and provides the necessary means to achieve this abstraction whereas
structure of a database means the data types, data semantics, relationships and
constraints that should hold on the data. Database designing is essentially a modeling
activity which maps the miniworld of the enterprise to database components.
l Various data models include Object based logical models, Record-based logical
models and Physical models.
l The Entity-Relationship (E-R) data model is based on a perception of a real world
that consists of a collection of basic objects, called entities, and of relationships
among these objects. The object-oriented model looks upon the world in terms of
discrete objects each possessing identifying characteristics and a set of behaviors.
The objects are taken to be capable of mutual interaction through message passing.
l Entity is an item - person or thing - that can be identified in the miniworld under
consideration.
l An attribute is a characteristic property of an entity. Each entity of the system
under consideration has a number of different attributes highlighting different aspect
of the entity. An entity is represented by the set of attributes it has. Every entity is
described by a set of (attribute, data value) pair. 55
Relational Database l A simple attribute is atomic and cannot be broken further down into simpler
Management System
components where as a composite attribute is composed of simpler values.
l A single-valued attribute takes only one value for a given entity while a multi-
valued attribute can take more than one value for a given entity.
l Derivable attribute can be obtained by subjecting other attributes to computation.
Since the value of the derived attribute can be computed from other attributes its
value need not be stored in the database.
l A collection of entities of the same type is referred to as entity set.
l A relationship set is a set of relationships of the same type.
l The objective of the E-R designing activity is to obtain the components of the E-R
model.
l E-R diagrams are very useful tools to develop and describe the E-R model of a
database. In its original form ER diagrams were proposed by Dr. Pin-Shan Chen in
the year 1976.
l E-R diagrams are composed of symbolic notations for entities, attributes and
relationships along with other aspects of these.
l Constraints are domain rules that must be followed by the ER components for
which they are defined. A common constraint laid on relationship is that of cardinality.
Cardinality constraint specifies the multiplicity of instances of entities related to
each other by a relationship.
l A key is a value (or set of values) that can serve the purpose of identifying instances
at various occasions is called a key.
l An attribute (or a set of attributes) that tells each instance from the other is called
primary key. An entity (or relationship) may have more than one primary key. One
of these possibilities is designated to be primary key the rest are referred to as
candidate keys. A set of attributes containing a primary key is called a superkey.

2.9 LESSON END ACTIVITIES

1. Identify the entities, their attributes (stated and implied) and relationships in the
following scenario.
In a library - Icon Private Library - there are currently 250 members. Membership
is open for all on submission of a non-refundable membership fee of Rs. 500.00.
The membership is confirmed by issuing a membership card that identifies the
member. Each member has to pay a monthly fee of Rs. 100.00 by 10th of each
month.
A member is entitled to get at the most 3 books issued at one time. The member is
allowed to keep a book for not more than 10 days after which he is fined at the rate
of Rs. 5.00 per day. In case of the lost book a member has to pay Rs. 50.00 in
addition to the printed price.
2. What is meant by structural constraint in the context of a database? Give a few
examples to elucidate your point.
3. Cite two examples of one-to-many relationship from practical life.
4. Consider the following ER diagram.

56
1. FNam LNam
Database Design
and ER Diagrams
Salary Locatio DeptN

ENam Sex Name

Works For
(1,1) (1,N)

Startdate
EMPN EMPLOYEE DEPARTMEN
(0,1) (1,1)
Manages

Address Hours
(0,N)
(1,N)
(0,N) WorksOn
(0,1)
(1,N) Controls
Supervisor (1,1)

Depends On

PROJECT

DEPENDENT
Name Location
Locatio

Name Sex PNO

Relationship BDate

Identify the following:

a. Entities
b. Attributes of the entities identified above
c. Relationships
d. Type of relationships
e. Cardinality of relationships
2. Name the weak entity in the Figure in question-1 if any. What makes this entity a
weak entity?

2.10 KEYWORDS
Attribute: A property of an entity whose data is to be stored.
Data: A representation of some measurable aspect of some fact.
Database: A repository of well-organized data.
Database administrator: The database user who is responsible for making decisions
and controlling the database.
Database management system: A computerized system that manages and controls an
electronic database.
Data model: A collection of concepts that describes the structure of a database such as
tables etc.
Entity-Relationship model: A data modeling tool that treats each object of the miniworld
as a separate unit having individual attributes and being related to one another.
ER diagram: A graphical representation of entities, attributes and relationships in a
miniworld.
57
Relational Database Information: A higher-level meaningful deduction obtained by processing data.
Management System
Key attribute: An attribute of an entity that uniquely determines each instance of an
entity.
Metadata: Data that describe data stored in a database.
Miniworld: (Also called Universe of Discourse) The small part of the world whose
related data are stored in a particular database.
Process: The set of activities that derives information from the given data.
Schema: The description of the data models in a database.
Weak entity: An entity type that does not have a key attribute of its own.

2.11 QUESTIONS FOR DISCUSSION

1. What are the privileges and responsibilities of a database administrator?
2. Describe various components of database schema with suitable examples.
3. What is meant by constraints in the context of a database? Give a few examples to
elucidate your point.
4. Write short notes on:
a. Entities
b. Attributes
c. Relationships
5. What is a weak entity? Explain with the help of suitable example.

Check Your Progress: Model Answers

i. The Entity-Relationship (E-R) data model is based on a perception of a real
world that consists of a collection of basic objects, called entities, and of
relationships among these objects.
ii. A relationship is defined as a collection of attributes (r1,r2,r3,....rn) such that
r1 ΠE1 and and so on. A relationship set is a set of relationships of the same type.

2.12 SUGGESTED READINGS

Peter Rob, Carlos Coronel - "Database Systems: Design, Implementation, and
Management", Seventh edition, Thomson Learning
Silberschatz, Korth, Sudarshan - "Database System Concepts", Fourth edition, McGraw-Hill
Elmasari Navathe - "Fundamentals of Database Systems", Third edition, Pearson
Education Asia
Suad Alagic, Relational Database Technology, Springer Ramón A. Mata-Toledo, Pauline
K. Cushman, Schaum's Outline of Fundamentals of Relational Databases, McGraw-Hill
Professional
Rajesh Narang, Database Management Systems, Prentice Hall of India
Vol.1 & 2; C.J. Date, An Introduction to Database Systems, Addison Wesley, 1983
Avi Silberschatz, Henry F. Korth, S. Sudarshan, Database System Concepts - 5th
58 edition, McGraw-Hill