UNIT –III

Building Blocks of an Entity–Relationship Diagram

ER diagram is a graphical modeling tool to standardize ER modeling. The
modeling can be carried out with the help of pictorial representation of entities,
attributes, and relationships. The basic building blocks of Entity-Relationship diagram
are Entity, Attribute and Relationship.
Entity
An entity is an object that exists and is distinguishable from other objects.
Ex: person, place,department etc
Entity Type
An entity type or entity set is a collection of similar entities. Some examples of
entity types are:
– All students in EDC, say STUDENT.
– All courses in EDC, say COURSE.
– All departments in EDC, say DEPARTMENT.
An entity may belong to more than one entity type. For example, a staff working
in a particular department can pursue higher education as part-time. Hence the same
person is a LECTURER at one instance and STUDENT at another instance.
Relationship
A relationship is an association of entities where the association includes one
entity from each participating entity type whereas relationship type is a meaningful
association between entity types.
– Teaches is the relationship type between LECTURER and STUDENT.
– Buying is the relationship between VENDOR and CUSTOMER.
– Treatment is the relationship between DOCTOR and PATIENT.
Attributes
Attributes are properties of entity types. In other words, entities are described in a
database by a set of attributes.
– Brand, cost, and weight are the attributes of CELLPHONE.
– Roll number, name, and grade are the attributes of STUDENT.
ER Diagram
The ER diagram is used to represent database schema. In ER diagram:
– A rectangle represents an entity set.
– An ellipse represents an attribute.
– A diamond represents a relationship.
– Lines represent linking of attributes to entity sets and of entity sets to
relationship sets.

DBMS Page 1
Entity Set 

Attribute 

Relationship 

Classification of Entity Sets

Entity sets can be broadly classified into:
 Strong entity.
 Weak entity.
 Associative entity.

Entity Set

Strong entity Weak entity Associative entity

Strong Entity
Strong entity is one whose existence does not depend on other entity.
Example
Consider the example, student takes course. Here student is a strong entity.

Student Takes Course

Weak Entity
Weak entity is one whose existence depends on other entity. In many cases, weak
entity does not have primary key

depends
EMPLOYEE DEPENDENTS

Associative entity
An associative entity is a term used in relational and entity–relationship theory. A
relational database requires the implementation of a base relation (or base table) to
resolve many-to-many relationships. A base relation representing this kind of entity is
called, informally, an associative table.

DBMS Page 2
An associative entity (using Chen notation)As mentioned above, associative entities
are implemented in a database structure using associative tables, which are tables that
can contain references to columns from the same or different database tables within
the same database.
Attribute Classification
Attribute is used to describe the
properties of the entity. This
attribute can be broadly classified
based on value and structure.
Based on value the attribute can
be classified into single value,
multivalue, derived, and null
value attribute. Based on
structure, the attribute can be classified as simple and composite attribute
Symbols Used in ER Diagram
The elements in ER diagram are Entity, Attribute, and Relationship. The different
types of entities like strong, weak, and associative
entity, different types of attributes like multivalued and
derived attributes and identifying relationship and their
corresponding symbols are
Single Value Attribute
Single value attribute means, there is only one value
associated with that attribute.
Multivalued Attribute
In the case of multivalue attribute, more than one value
will be associated with that attribute.
Derived Attribute
The value of the derived attribute can be derived from the values of other related
attributes or entities. In ER diagram, the derived attribute is represented by dotted
ellipse
Null Value Attribute
In some cases, a particular entity may not have any applicable value for an attribute.
For such situation, a special value called null value is created.
Composite Attribute
Composite attribute is one which can be further subdivided into simple attributes.
Relationship Degree
Relationship degree refers to the number of associated entities. The relationship
degree can be broadly classified into unary, binary, and ternary relationship.
Unary Relationship
The unary relationship is otherwise known as recursive relationship. In the
unary relationship the number of associated entity is one. An entity related to
itself is known as recursive relationship.
Binary Relationship

DBMS Page 3
In a binary relationship, two entities are involved. Consider the example; each staff
will be assigned to a particular department. Here the two entities are STAFF and
DEPARTMENT.
Ternary Relationship
In a ternary relationship, three entities are simultaneously
involved. Ternary relationships are required when binary
relationships are not sufficient to accurately describe the
semantics of an association among three entities
Specialization and Generalization (or)
Characteristics of Super type/Subtypes
There are two processors “Specialization” and “Generalization” that serve as
mental models in developing super type / subtype relationships.
Generalization: In data
modeling “Generalization
is the process of defining a
more general entity types
from a set of more
specialized entity types”.
Thus generalization is a
bottom-up approach
process. The example of
generalization is as show
in the following figure.
The above figure represents three entity
types car, truck motorcycle. At this stage
data modeler intends to represents this
separately on E-R diagram however, on
close examination, we see that three entity
types have a no. of attributes is common
and they are vehicle-identifier, vehicle-
name, price and engine displacement.
This fact suggests that each of the
three entity types is really a version a more general entity type. This more general
entity type vehicle, together with the resulting supertype/subtype relationship is
shown below.

DBMS Page 4
The entity CAR has the specific attribute no. of passengers, while truck has two
specific attributes capacity and cab-type. Thus, generalization has allowed us to group
entity types, along with their common attributes and at the same time preserve
specific attributes that are unique to each subtype.
The entry type motorcycle is not included in the relationship because it doesn’t satisfy
the subtype conditions.
Referring to the figure (d) you will notice that the only attributes of motorcycle are
those that are common to all vehicles, there are no attributes specific to motorcycles.
Motorcycle does not have a relationship to another entity type. Thus, there is no need
to create a motorcycle subtype. The fact that there is no motorcycle subtype
suggests that it must be possible to have an instance of vehicle that is not a member of
any of its subtypes.
b) Specialization: Specialization is “the process of defining one or more subtypes of
the supertype and forming supertype / subtype relationship”. Each subtype is formed
based on some distinguishing characteristic, such as attributes or relationships specific
to the subtype specialization is a top down process, direct reverse of generalization.
Fig. (b) Specialization to MANUFACTURED PART and PURCHASED
PART
The fig(a) shows an entity type named PART together with its attributes. The
identifier is part no and other attributes include description, unit-price, location,
Quantity_On_Hand, routing number and supplier. Supplier a multivolume attribute.
Since there may be more than one supplier with associated unit price for a part.
In discussion with users we discover that there are two possible sources for
parts some are manufactured internally, while other are purchased from outside
suppliers. Further, we discover that some parts of are obtained from both sources.
Some of the attributes of entity type in fig(a) apply to all parts regardless of
source. However, others depend on the source. Thus, routing-number applies only to
manufactured parts. While, supplier-id and unit-price apply only to purchased parts.
Analyst suggested that they create a new relationship between purchased part and
supplier. This relationship (named supplies) allows users to more easily associated
purchased parts with their suppliers. The attribute unit-price is now associated with
the relationship supplies, so that the unit price for a part may vary from one supplier
to another. These factors suggest that part should be specialized defining the subtypes
manufactured part and purchased part as show in the fig (b).
Combining Generalization and Specialization

DBMS Page 5
 Specialization and Generalization are both valuable technique for developing
supertype/subtype relationships. Which technique we use at particular time depends
on several factors such as the nature of the problem domain, previous modeling
efforts and personal preference. We should be prepare to use both approaches and to
alternate back and forth as dictated by the proceeding factors.
Specifying constraints in Supertype/Subtype Relationships.
The specifying constraint in supertype/subtype relationship allows us to
capture some of the important business rules that apply to these relationships; these
two most important types of constraints are “completeness” and “disjointness
constraints”.
i) Specifying completeness constraints:
“A completeness constraint addresses the question whether an instance of a
supertype must also be a member of at least one subtype”.
The completeness constraints have two possible rules.
a. Total specialization rule.
b. Partial specialization rule.
a. Total Specialization Rule:- “The total specialization rule specifies that each entity
instance of the supertype must be a member of some subtype in the relationship”.

This figure introduces the notation for total specialization. In this example, the
business rule is the following “A patient must be either an OUTPATIENT or
RESIDENT PATIENT” total specialization is indicated by the double line extending
from the patient entity type to the circle.
b) Partial Specialization Rule:- The partial specialization rule specifies that the
entity instance of the supertype is allowed not belong to any subtype.

DBMS Page 6
If a vehicle is a CAR, it must appear as an instance of CAR and if it is a truck, it must
appear as an instance of truck. However, if the vehicle is a motorcycle, if cannot
appear as an instance of any subtype. It is an example of partial specialization and it is
specified by the single line from the vehicle, super type to the circle.

II) Specifying Disjoint ness constraints:

A disjoint ness constraint addresses the question whether an instance of a supertype
may simultaneously a member of two or more subtypes.
The disjoint ness constraints have two possible rules.
a. The disjoint rule and
b. The overlap rule
a. The disjoint rule:- The disjoint rule specified that if an entity instance (of the
supertype) is a member of one subtype. It can’t simultaneously be a member of any
other subtype.

The business rule in this PATIENT example is the following

At any given time a PATEINT must be either an OUT PATIENT or a
RESIDENT PATIENT but cannot be both. This is the disjoint rule as specified by the
letter‘d’ in the circle joining the supertype and its subtypes.

DBMS Page 7
b. Overlap rule: - The overlap rule specified that an entity instance can
simultaneously be a member of two or more subtype. The following figure shows an
example of overlap rule. Below figure shows the entity type “PART” with its two sub
types, “MANUFACTURED PART” and “PURCHASED PART”. Some parts are
both manufactured and purchased.
The overlap rule is specified by placing the letter ‘O’ the circle. Notice in the
figure that the total specialization rule is also specified as indicated by the double line.
Thus any part must be either or purchased part or a manufactured part or it may
simultaneously be both of these.

II) Specifying subtype discriminators:

A subtype discriminator is an attribute of the supertype, whose values
determine the target subtype or subtypes.
a. Disjoint Subtypes:- An example of the use of a subtype discriminator is shown in
the following figure.
In the above figure, a new attribute “Employee - type” has been added to the
supertype to serve as subtype discriminator”. When a new employee is added to
supertype, this attribute is coded with one of three values as follows:
“H” – for hourly
“S” – for salaried
“C” – for consultant.

DBMS Page 8
 Depending on this code the instance is then assigned to the appropriate
subtype.
The notation we use to specify the subtype discriminator is also shown in the figure.
The expression “Employee-type” is placed next to the line leading from the supertype
to the circle. The value of the attribute that selects the appropriate subtype is placed
adjacent to the line leading to the subtype. Thus, for example to condition employee –
type = S, causes an entity instance to be inserted in to the SALARIED EMPLOYEE
subtype.
b. Overlaping Subtypes:- When subtypes overlap, a slightly modified approach must
be applied for the subtype discriminator. The reason is that a given instance of the
supertype may require that we create an instance in more than one subtype.
An example of this situation is shown in the following figure.

The figure shows an entity PART and its overlapping subtypes. A new attributed
named part-type has been added to PART Part type is a composite attribute with
components manufactured? And purchased? Each of these attributes is a Boolean
Variable (i.e., it takes only the values yes “Y” and No “N”). When a new instance is
added to PART, these components are coded as follows.

DBMS Page 9
Normalization
Normalization is a design technique that is widely used as a guide in
designing relational databases. Normalization is essentially a two step process that
puts data into tabular form by removing repeating groups and then removes duplicated
data from the relational tables.
Normalization theory is based on the concepts of normal forms. A relational table is
said to be a particular normal form if it satisfies certain set of constraints
Advantages of Normalization
 Avoids data modification (INSERT/DELETE/UPDATE) anomalies as each
data item lives in One place
 Greater flexibility in getting the expected data in atomic granular
 Normalization is conceptually cleaner and easier to maintain and change as
your needs change
 Fewer null values and less opportunity for inconsistency
 A better handle on database security
 Increased storage efficiency
 The normalization process helps maximize the use of clustered indexes, which
is the most powerful and useful type of index available. As more data is
separated into multiple tables because of normalization, the more clustered
indexes become available to help speed up data access
Disadvantages
1. Requires much more CPU, memory, and I/O to process thus normalized data gives
reduced database performance
2. Requires more joins to get the desired result. A poorly-written query can bring the
database down
3. Maintenance overhead. The higher the level of normalization, the greater the
number of tables in the database.
Basic and Higher Normal forms:
Normal forms are classified into two main categories they are
1. Basic Normal Forms
2. Higher Normal Forms.
1) Basic Normal Forms:
The basic normal forms are
 First normal form

DBMS Page 10
  Second normal form
 Third normal form
First Normal Form:
A relation is in a first normal form if it contains no multi-valued attribute.
For example the relation EMPLOYEE contains the attributes like Emp-Id,
Emp-Name, Sal, and gender. Here is no multi valued attribute. So the relation
EMPLOYEE is in first normal form.
EMPLOYEE
Emp- Emp-Name Sal Gender
No
Second Normal Form (2NF):
A relation is in second normal form if it is in first normal form and every non-
key attribute is fully functionally dependent on the primary attribute. That means no
partial functional dependency.
If a relation is in second normal form if any one of the following conditions apply.
i. A relation contains only one primary key.
ii. No non-key attributes in the relation.
iii. Every non-key attribute is functionally dependent on the full set of primary
key attributes (fully functional dependency)
For example the relation EMPLOYEE contains the attributes like Emp-Id, Emp-
Name, course-Id, Sal, and Date-completed. In this example the primary key for this
relation is composite key of Emp-Id, Course-Id. Here the relation employee is not in
second normal form because the non-key attribute Emp-Name, Sal are functionally
dependent on the part of the primary key (Emp-Id, Partial functional dependency). So
we decompose the relation EMPLOYEE into new relations EMPLOYEE.
EMPLOYEE
Emp-No Course-Id Emp-Name Sal Date-completed
Course-Id → Date-completed
Emp-Id→ Emp-Name
Emp-Id → Sal
EMPLOYEE
Emp-Id Emp-Name Sal
COURSE
Emp-Id Course_Id Date-completed

DBMS Page 11
Third Normal Form (3NF):
A relation is in 3rd normal form if it is in second normal form and no transitive
dependency. A transitive dependency in a relation is a functional dependency between
two or more non-key attributes. For example consider the following relation SALEs.
SALES.
Cust- Cust-Name Salesperson-Id Region
Id
In the above relation cust-Id is the primary key. So all of the remaining
attributes are functionally dependent on this attribute. However there is a transitive
dependency. The attribute region is functionally dependent the attributes salesperson-
Id. So we decompose the above relation into new relations that satisfy our 3 rd normal
form.
CUSTOMER
Cust-Id Cust-Name Salesperson-Id
SALES
Salesperson-Id Region
Advanced Normal Forms/Higher Normal Forms:
Advanced Normal Forms are
1. Boyce codd normal form (BCNF)
2. Fourth normal form
3. Fifth normal form
1) Boyc/ Codd Normal Form:
A relation is in Boyce codd normal form if it is in third normal form and the
determinants are candidate keys. For example consider a relation STUDENT with
attributes like St.No, subject, Adviser.
In the above relation primary key is a composite key of St.No, subject. Here
two functional dependencies occur.
STUDENT
St-No Subject Adviser
St-No adviser
Subject Adviser

DBMS Page 12
 In the above second functional dependency determinant is adviser. It is not a
candidate key. So the above relation cannot follow Boyce codd normal form. So we
decompose the above relation into new relations.
STUDENT
St-No Adviser

ADVISER
Subjec Adviser
t
2) Fourth Normal Form:
A relation is in fourth normal form if it is in Boyce codd normal form and no
multi valued dependency. Here multi-valued dependency is a functional dependency
that exists a non-key attribute is functionally dependent on two or more sets of
primary key attributes.
For example consider a relation student contains attributes like st-No, st-
Name, course-Id and grade. Here primary key is a composite key of st-No, st-Name,
course-Id. In the above example the non-key attribute grade is functionally dependent
on st-no, course-Id, and st-name, course-Id.
STUDENT
St- St-name Course-Id Grade
No
St-No, course-Id grade
St-Name, course-Id grade
The above relation contains multi-valued dependency. So it is not in fourth
normal form. To avoid the multi-valued dependency we decompose the above
relations into new relations.

St- St-Name
No

St- Course-Id Grade

No
3) Fifth Normal Form (5NF):- (Domain Normal
Form) (Projection-join Normal Form)

DBMS Page 13
 A relation is in fifth normal form if it is in fourth normal form and that
contains joined dependency. Here join-dependency means if a relation contains
minimum of 3 attributes and every attribute may functionally dependent on the
remaining attributes. For example consider a relation CLASS with attributes like
subject, teacher and text-book. Here primary key is a composite key of subject,
teacher, text-book. The above relation CLASS is not in fifth normal form because it
satisfies join-dependency. So we decompose the above relation into new relations.
Subject Teacher Text-book

Subject, teacher --- text-book Subjec Teacher

t
Text-book, subject --- teacher
Teache Text-book
r
Text-book, teacher --- subject
Text-book Subject

Aggregation and Composition

Relationships among relationships are not supported by the ER model. Groups
of entities and relationships can be abstracted into higher level entities using
aggregation. Aggregation represents a “HAS-A” or “IS-PART-OF” relationship
between entity types. One entity type is the whole, the other is the part. Aggregation
allows us to indicate that a relationship set participates in another relationship set. The
car has various components like tires, doors, engine, seat, etc., which varies from one
car to another. Relationship drives is insufficient to model the complexity of this
system. Part of relationships allow abstraction into higher level entities. In this
example engine, tires, doors, and seats are aggregated into car.

DBMS Page 14
 Composition is a stronger form of aggregation where the part cannot exist
without its containing whole entity type and the part can only be part of one entity
type. Consider the example of DEPARTMENT has PROJECT. Each project is
associated with a particular DEPARTMENT. There cannot be a PROJECT without
DEPARTMENT. Hence DEPARTMENT has PROJECT is an example of
composition.
Relationships within the relational data base/ Mapping cardinalities :
Mapping cardinalities (or) cardinality ratios express the number of entities to which
another entity can be associated via a relationship set. Mapping cardinalities are most
useful in describing binary relationship sets although occasionally they contribute to
the description of relationship sets that involve more than two entity sets.
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following.
(i) One – to – One: An entity in A is associated with at most one entity in B; and an
entity in B is associated with at must one entity in A
A B

a b
1 1

a b
2 2

a b

Example: One – to - One

DBMS Page 15
 Employee Parking Place
Is-assigned
One - to - One
The above example indicates that an employee is assigned one parking place,
and each parking place is assigned to one employee.
(ii)One – to – Many An entity in A is associated with any b1
number of entities in B. An entity in B, however can be a b2
associated with at most one entity in A. 1
b3
a b4
2
b5

One – to - Many
CUSTOMER ORDER
Submit

(iii) Many – to – One An entity in A is associated with at most one entity in B. An

entity in B however, can be associated with any number of entities in A.
A B

a1
b
a2 1

a3 b

a4 Many – to - One
Example:

PRODUCT Contains Product_Line

Many - to - One

The above example indicates that each product belongs to only one product
line and a product line may contain several products.
(iv) Many-to-Many An entity in A is associated with any number of entities in B and
an entity in B is associated with any number of entities in A.
A B

a b
1 1

DBMS a b Page 16
2 2
 Many – to - Many
Example:
STUDENT Registers- Course
for

The above example shows that a student may register for more than one
course and that each course may have many student registrants.

Entity Relationship model constructs(ER Model)

(OR)
Data model basic building blocks
The basic constructs of the entity relationship model are entities, relationships
and attributes. The richness of the E-R Model allows designers to model real world
situations accurately and expressively, which helps account for the popularity of the
model.
Entity:
An entity is an object that may represents person, place, object, event or concept in
the user environment about which the organization wishes to maintain data.
Eg: Employee, Student, Store, warehouse, Machine, Registration, Account,
course.
Entity type versus Entity Instance:
Entity Type: An entity type “is a collection of entitles that share common properties
or characteristics”. Each type in an E-R model is given a name. Since the name
represents a collection of items, all it is always singular. We use capital letters for
names of entity types. In an E-R diagram the entity name is placed inside the box
representing the entity type.
Entity Instance: An entity instance “is a single occurrence of an entity type”. An
entity type is described just once (Using metadata) in database, while many instances
of that entity type may be represented by data stored in the databases.
Strong Vs weak entity types:

DBMS Page 17
Strong entity: An entity that exists independently of other entity type, then it is called
strong entity type or An entity set that has a primary key is termed as a strong entity
set. Strong entity is denoted by a symbol single lined Box.
Weak entity: An entity set may not have sufficient attributes to form a primary key
such entity set is termed as weak entity set (or) An entity type whose existence
depends on some other entity type is called weak entity type. weak entity type has no
meaning in the E- R diagram without the entity on which it depends. the entity type
on which the weak entity type depends is called “the identifying owner” (or) simply
called “owner” . Weak entity is denoted by a symbol double lined Box.

Identity Relationship : The relationship that associates the weak entity set with an
owner is the identifying relationship.
Attributes: property or characteristic of an entity type that is of interest to the
organization is called attribute. An attribute is denoted by a symbol ellipse.
Ex:

FACULTY

F_Na
me M_ N
ame

L_Na
F_Id me
Name

Dob
Skill FACULTY

Qual
ificat
ion
Age

In above example F_Id,Name,Dob,Age,Skill Qualification are attributes of the

FACULTY entity.
Types of attributes :
1. Simple Vs Composite Attribute:
Simple attribute:

DBMS Page 18
A ‘Simple” or atomic attribute is an attribute that cannot be broken down into smaller
components. In above Example F_Id, Dob, Skill, Age, Qualificaton are Simple
attributes.
Composite attribute: A “composite” attribute is an attribute that can broken down
into component parts. In above Example Name is Composite attribute. Because it is
broken in to 3 parts(Components) namely F_Name, M_Name, and L_Name.
2. Single valued Vs Mutlivalued Attribute:
Single valued attribute :A “Single valued’ attribute is an attribute that takes only one
value for a given entity instance.
Eg : The F_Id attribute of an entity FACULTY takes only one value for each entity
instance.
Mutlivalued Attribute: A “multi valued” attribute is an attribute that may take
more than one value for a given entity instance. We indicate a multi valued attribute
with a double lined ellipse.

Ex: Consider a FACULTY entity set with the attribute Skill. Any particular faculty
may have Skill in more than one topic.
3. Null attributes: A null value is used when an entity does not have a value for an
attribute.
4. Stored Vs Derived Attributes :
Stored attribute: Some attribute values are calculated or derived from other
related attribute values that stored in the database.
Ex : In FACULTY entity type F_Id, Dob are stored attributes.
Derived Attribute: A “derived” attribute is an attribute whose values can be
calculated from related attribute values. We indicate a derived attribute in an E-R
Diagram by using an ellipse with a dashed line.
Ex : The FACULTY entity type has Age attribute. If the users need to know Age, that
value must be derived from the attribute Dob.
5. Identifier attribute or Primary Key: An identifier is an attribute that uniquely
identifies individual instances of an entity type. The identifier for the Faculty entity
type is F_Id. Each entity instance must have a single value for the attribute and the
attribute must be associated with entity. We underline identifiers name on the E-R
Diagram.
Primary Key: A Primary key is a set of one or more attributes that can uniquely
identify tuples within the relation.

DBMS Page 19
Composite identifier or Composite key attribute: A composite identifier is an
identifier that consists of a composite attribute.
The following figure shows the entity set flight with the composite identifier-
flight-id. The Flight-id composite attribute inturn has component attributes flight-no
and date. This combination is required to uniquely identify individual occurrences of
flight.
Flight-no date

No.of
Flight-id passengers

Primary key Flight

Relationships:
A relationship is an association among the instances of one (or) more entity
types i.e., of interest to the organization.
Eg : Consider the entity type employee and course where courses represents training
courses that may be taken by employees. To track courses that have been completed
by particular employees. We define a relationship called “Completes” between two
entity types as shown in the following figure.
Relationship type (Completes):
Course- Course-
id title
Employee Employee-
name
-id
Topic

Birthdate

Employee Comple Course

tes

Relationship instances:
Employee Course
Raju C++
Kiran Java

DBMS Page 20
 Suman COBOL
Hema C
This is a many-To- many relationship since each employee may complete any
no. of course, while a given course may be completed by any no. of employees.
1. Associative Entities : An associative entity is an entity type that associates
the instances of one or more entity types and contains attributes that are
peculiar to the relationships between those entity instances,
In the E-R model associative entities are represented with the diamond
relationship symbol enclosed within entity box. The purpose of this symbol is
to preserve the information that the entity was initially specified as a
relationship on E-R Model.
An associative entity (Certificate):”
Employe Employee- Certificate-
e-id name DOC Cours
Number
e -id Course -
Title

EMPLOYEE CERTIFIC Course

ATE

Figure (b) shows the relationship “completes” converted to an associative

entity type. In this case the training department for the company has decided to award
a certificate to each employee who completes a course. Thus, the entity is named
certificate which certainly has independent meaning to end users. Each certificate has
a number that serves as a identifier. The attribute date completed is also included.
Constraint:
A constraint is a restriction placed on the data. Constraints are important because they
help to ensure data integrity. Constraints are normally expressed in the form of rules.

Different Keys:
Keys: It is important to be able to specify how rows in a relation are distinguished
conceptually, rows are distinct from one another, but from a database perspective the

DBMS Page 21
difference among them must be expressed in terms of their attributes. Keys come here
for a rescue.
Primary key: A primary key is a set of one (or) more attributes that can uniquely
identify tuple within the relation.
Ex: In our sample database, sup # is the primary key for supplier’s relation (table) as
it contains unique value for each tuple in the relation.
Composite Primary Key: In some tables, combination of more than one attribute
provides a unique value for each row. In such tables, the group of these attributes is
declared as primary key. In such cases, the primary key consists of more than one
attribute; it is called composite-primary-key.
Ex: Supp # and item # is the primary key for the shipments relation (table).
Candidate Key: All attribute combinations inside a relation that can serve as primary
key are candidate keys as they are candidates for the primary key position.
Ex: In our sample database, there are two candidate keys supp # and sup-name in the
suppliers relation. Both of these attributes contain unique values for each tuple.
Super Key
A super key is a column (or) set of columns that uniquely identifies a row
within a table.
Ex:
Given table : Employees { employee-id, first-name, sur-name, sal }
Possible super keys are :
{ Employee_Id}
{ Employee_Id, First_Name }
{ Employee_Id, First_Name, Surname }
{ Employee_Id, First_Name, Surname, Sal }
Secondary Key: It is defined as a key that is used strictly for data retrieval purposes.
Ex: Suppose customer data are stored in a CUSTOMER table in which the
customer number is the primary key. Suppose, that some of the customers forget their
number? Data retrieval for a customer can be facilitated when the customer’s last
name and phone number are used. In that case, the primary key is the customer
number, the secondary key is the combination of the customer’s last name and phone
number.
Foreign Key: A non-key attribute, whose values are derived from the primary key of
some other table, is known as foreign-key in its current table.
SUPPLIER

DBMS Page 22
 Supp # Supp-Name Status city
S1 Britannia 10 Delhi
S2 New-Bakers 30 Mumbai
S3 Mother Dairy 10 Delhi
S4 Cockz 50 Bangalore
S5 Haldiram 40 Jaipur
SHIPMENT
Supp # Item # Qty-supplied
S1 12 10
S1 13 20
S1 16 20
S2 14 20
S2 15 10
S3 11 10
S3 17 10
S4 18 30
S5 19 30

Data dictionary and System catalog

Data Dictionary:
An integral part of RDBMS is the data dictionary which stores Meta
data, (or) information about the database, including attribute names and definitions for
each table in the database. The data dictionary is usually a part of the system catalog
that is generated for each database.
The system catalog describes all database objects, including table-
related data such as table names, table creators (or) owners, column names and data
types, foreign keys and primary keys, index files, authorized users, user access
privileges and so forth. The system catalog is created by the DBMS and the
information is stored in system tables, which may be queried in the same manner as
any other data table, if the user has sufficient access privileges.
The system catalog automatically produces database documentation. As new
tables are added to the database, that documentation also allows the RDBMS to check
for and eliminate homonyms and synonyms.
Homonyms are similar-sounding words with different meanings, such
as boar and bore (or) identically spelled words with different meanings such as fair
( meaning “just”) and fair (meaning “festival”).

DBMS Page 23
 In a database context, the word homonym indicates the use of the
same attribute name to label different attributes. To lesser confusion, you should
avoid database homonyms, the data dictionary is very useful in this regard.
A synonym is the opposite of a homonym and indicates the use of different
names to describe the same attribute. For ex, can and auto refer to the same object.
Synonyms must be avoided.
Integrity constraints
Integrity Rules:
Relational database integrity rules are very important to good database design.
Many RDBMSs enforce integrity rules automatically. However, it is much safer to
make sure that your application design conforms to the entity and referential integrity
rules.
Entity Integrity:
All primary key entries are unique, and no part of a primary key may be null. Each
row will have a unique identity, and foreign key values can properly reference
primary key values.
Referential Integrity:
A foreign key may have either a null entry, as long as it is not a part of its tables
primary key, or an entry that matches the primary key value in a table to which it is
related. (Every non-null foreign key value must reference an existing primary key
value.)
Integrity Constraints: The relational data model includes several types of integrity
constraints. The purpose of integrity constraints is to implement the business rules in
the database. In relational data model several types of integrity constraints are
1. Domain Integrity Constraints:
A domain is a set of values that may be assigned to an attribute. All of the
values that may appear in a column of a table must be taken from the same domain. A
domain consists of values like column name, data type, size and allowable values.
Domain integrity constraints are 1) Not Null and 2) Check. The Not Null constraint is
used to avoid null values. The check constraint is used to specify a condition for an
attribute. In relational data model NULL values is not equal to zero or Null strings.
Here one null value is not equal to another null value.
2. Entity Integrity Constraints:

DBMS Page 24
 Mainly Entity integrity constraints are two types. They are (i) Primary key and
(ii) Unique:
Every primary key attribute is non-null and contains unique values. In some
cases a particular attribute cannot be assigned a data value. These are two situations.
Where this is likely to occur either there is no applicable data value (or) the applicable
data value is not known. In this case we use the entity integrity constraint unique.
3. Referential Integrity Constraints:
In the relational data model association between the tables are defined with the
help of Referential integrity constraints (foreign key). For example the association
between the CUSTOMER and ORDER tables is identified by including the customer-
Id attribute as foreign key in ORDER table.

CUSTOMER
Customer-Id Cust-Name Add
Primary key
ORDER
Order-Id Order description Customer-Id

Foreign key
A referential integrity constraint is a rule that maintains consistency among the
rows of two relations. The says that if there is a foreign key in one relation, the
foreign key values must match the primary key values in another relation.

Logical view of Data

Logical view of data: A collection of interrelated files and a set of programs that
allow users to access and modify these files is known as a database management
system.
The database stores and manages both data and meta data. The DBMS
manages and controls access to the data and the database structure. Such an
arrangement i.e; placing the DBMS between the application and the database,
eliminates most of the file system’s internet limitations.
The relational data model allows the designer to focus on the logical
representation of the data and its relationships, rather than on physical storage details.
The relational model enables you to view data logically rather than physically.

DBMS Page 25
 The use of a table, how the advantages of structural and data independence. A
table does resemble a file from a conceptual point of view. Because you can think of
related records as being stored in independent tables, the relational data base model is
much easier to understand than the hierarchical and network models. Logical
simplicity tends to yield simple and effective database design methodologies. The
table plays such a prominent vole in the relational model.
Tables and their characteristics
The logical view of the relational database is facilitated by the creation of data
relationships based on a logical construct known as a relation. Because a relation is a
mathematical construct, end-users find it much easier to think of a relation as a table.
A table is perceived as a two-dimensional structure composed of rows and columns. A
table is also called a relation because the relational model’s creator, E.F. Codd, used
the term relation as a synonym for table.
Characteristics of a Relational Table
1. A table is perceived as a two-dimensional structure composed of rows and
columns.
2. Each table row (tuple) represents a single entity occurrence within the
entity set.
3. Each table column represents an attribute, and each column has a distinct
name.
4. Each row/column intersection represents a single data value.
5. All values in a column must conform to the same data format.
6. Each column has a specific range of values known as the attribute
domain.
7. The order of the rows and columns is immaterial to the DBMS.
8. Each table must have an attribute or a combination of attributes that
uniquely identifies each row.

Relational set operators

The relational algebra is a collection of operations on relations. Each operation
takes one (or) more relations as its operand (s) and produces another relation as its
result. Relational algebra defines the theoretical way of manipulating table contents
using the eight relational operators. The operations defined in relational algebra

DBMS Page 26
include select, project, Cartesian product, union, set difference, set intersection,
natural join, division e.t.c; The select and project are unary operations since they
operate on one relations.
1. The select operation
The select operation selects tuples (horizontal subset) from a relation that
satisfy a given predicate (i.e.: a given condition). The selection is denoted by s
(sigma). Ex: To select those tuples from Items relation where the price is more than
14.00, we shall write
price > 14.00 (items)
ITEM ITEM
Item # Items-Name Price Item # Item-Name price
I1 Milk 15.00 I1 Milk 15.00
I2 Cake 5.00 I7 Ice cream 16.00
I4 Milk bread 14.00 I9 Namkeen 15.00
I5 Plain biscuit 6.00
I6 Cream biscuit 10.00
Fig (b)
I7 Ice cream 16.00
I8 Namkeen 15.00

The relation that results from the above query is as shown in fig (b)
2. The project operation
The project operation yields a “vertical” subset of a given relation. The projection lets
you select specified attributes in a specified order. Projection is denoted by Ù (Pi) Ex:
To project supplier names and their cities from the relation suppliers, we shall write
Ù Supp-Name, city (suppliers)
The relation resulting from this query is as shown in fig (b)
SUPPLIER
Supp # Supp-Name Status city
S1 Britannia 10 Delhi
S2 New Bakers 30 Mumbai
S3 Mother Dairy 10 Delhi
S4 Cookz 50 Bangalore
S5 Haldiram 40 jaipur

DBMS Page 27
 Fig (a)
SUPPLIER
Supp-Name City
Britannia Delhi
New Bakers Mumbai
Mother dairy Delhi
Cookz Bangalore
Haldiram jaipur

Fig (b)
3. The Cartesian product operation
The Cartesian product is a binary operation and is denoted by a cross (X). The
Cartesian product of two relation A and B is written as A x B. The Cartesian product
yields a new relation which has a degree (number of attributes) equal to the sum of the
degrees of the two relations. Operated upon. The Cartesian product of two relations
yields a relation with all possible combinations of the tuples of the two relations
operated upon. Let us consider how does it work let us assume there are two relations
student and Instructor
STUDENT INSTUUCTOR
Stud # Stud-Name Hosteler
INST# INST-Name subject
S001 Meenakshi Y
101 K.Lal English
S002 Radhika N
102 R.L.Arora Maths
S003 Abhinav N
The resulting relation has been shown in below figure student x Instructor

The resulting relation contains all possible combinations of tuples of the two relations.
STUDENT_INSTUUCTOR
Stud # Stud-Name Hosteler INST# INST-Name Subject
S001 Meenakshi Y 101 K.Lal English
S001 Meenakshi Y 102 R.L.Arora Maths
S002 Radhika N 101 K.Lal English
S002 Radhika N 102 R.L.Arora Maths
S003 Abhinav N 101 K.Lal English
S003 abhinav N 102 R.L.Arora Maths

4. The union operation

DBMS Page 28
 The union operation is a binary operation that requires two relations as its
operands. It produces a third relation that contains tuples from both the operand
relations. The union operation is denoted by U. To denote the union of two relations
X and Y we will write X U Y
One thing must be remembered about union that is both the operand relations
must be union-compatible. For a union operation A U B to be valid, the following two
conditions must be satisfied by the two operands A and B.
1. The relations A and B must be of the same degree. That is, they must have the
same number of attributes.
2. The domains of the ith attributes of A and the i th attribute of B must be the
same.
A B

AUB
consider that we have following two relations Drama and Song, then the result
of SONG U DRAMA will be as shown in Fig (c)
DRAMA SONG
Roll No. Name Age
2 Manya 15
10 Rishabh 15
13 Kush 15

Result of SONG V DRAMA will be

Roll No. Name Age
2 Manya 15
10 Rishabh 15
13 Kush 15
17 Swathi 14

Fig (c)
In the result an relation, all the duplicating tuples will be automatically removed.

DBMS Page 29
 5. The set Difference operation
The set difference operation, denoted by-(minus) allows us to find tuples that
are in one relation but not in another. The expression A-B results in a relation
containing those tuples in A but not in B.

DRAMA SONG A B
Roll No. Name Age
2 Manya 15
10 Rishabh 15
13 Kush 15

Result of DRAMA_SONG will be

Roll No. Name Age
17 Swathi 14
6. The set Intersection operation
The set intersection operation finds tuples that are common to the two operand
relations. The set intersection operation is denoted by Ç. The A Ç B will yield a
relation having tuples common to A and B.
DRAMA SONG A B
Roll No. Name Age
2 Manya 15
10 Rishabh 15
13 Kush 15
AÇB

Result of DRAMA Ç SONG will be

Roll No. Name Age
13 Kush 15
7. The join operation
The join operation joins two relations to form a new relation on the basis of
one common column the two operand relations have. That is, if two tables each have a
column defined over some common domain, they may be joined over those two
columns, the result of the join is a new, wider table in which each row is formed by

DBMS Page 30
concatenating two rows, one from each of the original tables, such that the two rows
have the same value in those two columns.
Ex: If we have a relation suppliers and another relation say clients as shown below.

SUPPLIER CLIENT
Supp # Supp-Name Status city
Client # Client-Name C city
S1 Britannia 10 Delhi
C101 ABC Co. Delhi
S2 New Bakers 30 Mumbai
C102 XYZ Co. Jaipur
S3 Mother 10 Delhi
C104 ZIGS Co. jaipur
S4 Dairy 50 Bangalore
S5 Cockz 40 jaipur
Haldiram

ow, if tables suppliers and clients are joined over city columns, the result will be as
shown.
SUPPLIER_CLIENT
Supp # Supp-Name Status City Client # Client-Name C City
S1 Britannia 10 Delhi C101 ABC Co. Delhi
S3 Mother 10 Delhi C101 ABC Co. Delhi
S5 Dairy 40 Jaipur C102 XYZ Co. Jaipur
S5 Haldiram 40 Jaipur C104 ZIGS Co. Jaipur
8. Division Operation: The DIVIDE operation uses one single-column table (i.e.
column “a”) as the divisor and one 2-column table (i.e. columns “a” and “b”) as the
dividend. The tables must have a common column (i.e. column “a”.) The output of the
DIVIDE operation is a single column with the values of column “a” from the dividend
table rows where the value of the common column (i.e. column “a”) in both tables
match.

E.F. CODD’S RELATIONAL DATABASE RULES

In 1985, Dr.E.F.Codd published a list of 12 rules to define a relational
database system. The reason Dr.Codd published the list was his concern that many
vendors were marketing products as “relational” even though those products did not
meet the minimum relational standards. Dr.Codd’s list below serves as a frame of
reference for what a truly relational database should be.

DBMS Page 31
1. Information Representation: All information in a relational database must be
logically represented as column values in rows within tables.
2. Guaranted Access: Every value in a table is guaranteed to be accessible through a
combination of table name, primary key value, and column name.
3. Systematic Treatment of Nulls: Nulls must be represented and treated in a
systematic way, independent of data type.
4. Dynamic On-Line Catalog Based on the Relational Model: The metadata must
be stored and managed as ordinary data, that is, in tables within the database. Such
data must be available to authorized users using the relational database relational
language.
5. Comprehensive Data Sublanguage: The relational database may support many
languages. However, it must support one well defined, declarative language.
However, it must support one well defined, declarative language with support for data
definition, view definition, data manipulation (interactive and by program), integrity
constraints, authorization, and transaction management (begin, commit, and rollback).
6. View Updating: Any view that is theoretically updatable must be updatable
through the system.
7. High-Level Insert, Update and Delete: The database must support set-level
inserts, updates, and deletes.
8. Physical Data Independence: Application programs and ad hoc facilities are
logically unaffected when physical access methods or storage structures are changed.
9. Logical Data Independence: Application programs and hoc facilities are logically
unaffected when changes are made to the table structures that preserve the original
table values (changing order of column or inserting columns.)
10. Integrity Independence: All relational integrity constraints must be definable in
the relational language and stored in the system catalog, not at the application level.
11. Distribution Independence: The end users and application programs are unaware
and unaffected by the data location (distributed vs. local databases).
12. Nonsubversion: If the system supports low-level access to the data, there must
not be a way to bypass the integrity rules of the database.
13. Rule Zero: All preceding rules are based on the notion that in order for a database
to be considered relational, it must use its relational facilities exclusively to manage
the database.

DBMS Page 32
DBMS Page 33