UNIT -2

Entity Relationship Diagram – ER Diagram in DBMS

An Entity–relationship model (ER model) describes the structure of a database with the help
of a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model
is a design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.

What is an Entity Relationship Diagram (ER Diagram)?

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute
of a table in database, so by showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database. Lets have a look at a simple ER diagram to
understand this concept.

Facts about ER Diagram Model:

ER model allows you to draw Database Design
It is an easy to use graphical tool for modeling data
Widely used in Database Design
It is a GUI representation of the logical structure of a Database
It helps you to identifies the entities which exist in a system and the relationships between those
entities

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram

Helps you to define terms related to entity relationship modeling
Provide a preview of how all your tables should connect, what fields are going to be on each
table
Helps to describe entities, attributes, relationships
ER diagrams are translatable into relational tables which allows you to build databases quickly
ER diagrams can be used by database designers as a blueprint for implementing data in specific
software applications

A simple ER Diagram:

In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.
Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these
terms in detail in the next section (Components of a ER Diagram) of this guide so don’t worry
too much about these terms now, just go through them once.

Rectangle: Represents Entity sets.

Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set

Components of a ER Diagram
As shown in the above diagram, an ER diagram has three main components:
1. Entity
2. Attribute
3. Relationship

1. Entity

An entity is an object or component of data. An entity is represented as rectangle in an ER

diagram.
For example: In the following ER diagram we have two entities Student and College and these
two entities have many to one relationship as many students study in a single college. We will
read more about relationships later, for now focus on entities.

Weak Entity:

An entity that cannot be uniquely identified by its own attributes and relies on the relationship
with other entity is called weak entity. The weak entity is represented by a double rectangle.
For example – a bank account cannot be uniquely identified without knowing the bank to which
the account belongs, so bank account is a weak entity.

Weak Entities

A weak entity is a type of entity which doesn't have its key attribute. It can be identified
uniquely by considering the primary key of another entity. For that, weak entity sets need to
have participation.
In above example, "Trans No" is a discriminator within a group of transactions in an ATM.Let's
learn more about a weak entity by comparing it with a Strong Entity

Strong Entity Set Weak Entity Set

Strong entity set always has a primary key. It does not have enough attributes to build a
primary key.

It is represented by a rectangle symbol. It is represented by a double rectangle

symbol.

It contains a Primary key represented by the It contains a Partial Key which is represented
underline symbol. by a dashed underline symbol.

The member of a strong entity set is called The member of a weak entity set called as a
as dominant entity set. subordinate entity set.

Primary Key is one of its attributes which In a weak entity set, it is a combination of
helps to identify its member. primary key and partial key of the strong
entity set.

In the ER diagram the relationship between The relationship between one strong and a
two strong entity set shown by using a weak entity set shown by using the double
diamond symbol. diamond symbol.

The connecting line of the strong entity set The line connecting the weak entity set for
with the relationship is single. identifying relationship is double.

2. Attribute
An attribute describes the property of an entity. An attribute is represented as Oval in an ER
diagram. There are four types of attributes:
1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute
1. Key attribute:

A key attribute can uniquely identify an entity from an entity set. For example, student roll
number can uniquely identify a student from a set of students. Key attribute is represented by
oval same as other attributes however the text of key attribute is underlined.

2. Composite attribute: An attribute that is a combination of other attributes is known as

composite attribute. For example, In student entity, the student address is a composite attribute
as an address is composed of other attributes such as pin code, state, country.

3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented
with double ovals in an ER Diagram. For example – A person can have more than one phone
numbers so the phone number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is
represented by dashed oval in an ER Diagram. For example – Person age is a derived attribute
as it changes over time and can be derived from another attribute (Date of birth).
E-R diagram with multivalued and derived attributes:

3. Relationship

Cardinality: Defines the numerical attributes of the relationship between two entities or entity
sets.

A relationship is represented by diamond shape in ER diagram, it shows the relationship among

entities. There are four types of cardinal relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it
is called one to one relationship. For example, a person has only one passport and a passport is
given to one person.

2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another entity
then it is called one to many relationship. For example – a customer can place many orders but
a order cannot be placed by many customers.
3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another entity
then it is called many to one relationship. For example – many students can study in a single
college but a student cannot study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of another
entity then it is called many to many relationship. For example, a can be assigned to many
projects and a project can be assigned to many students.

Total Participation of an Entity set

A Total participation of an entity set represents that each entity in entity set must have at least
one relationship in a relationship set. For example: In the below diagram each college must
have at-least one associated Student.
Steps to Create an ERD (E-R Digram)
Following are the steps to create an ERD.

Let's study them with an example:

In a university, a Student enrolls in Courses. A student must be assigned to at least one or more
Courses. Each course is taught by a single Professor. To maintain instruction quality, a
Professor can deliver only one course
Step 1) Entity Identification
We have three entities
 Student
 Course
 Professor

Step 2) Relationship Identification

We have the following two relationships
 The student is assigned a course
 Professor delivers a course

Step 3) Cardinality Identification

For them problem statement we know that,
 A student can be assigned multiple courses
 A Professor can deliver only one course

Step 4) Identify Attributes

You need to study the files, forms, reports, data currently maintained by the organization to
identify attributes. You can also conduct interviews with various stakeholders to identify
entities. Initially, it's important to identify the attributes without mapping them to a particular
entity.
Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an
attribute is to be paired with exactly one entity. If you think an attribute should belong to more
than one entity, use a modifier to make it unique.
Once the mapping is done, identify the primary Keys. If a unique key is not readily available,
create one.

Entity Primary Key Attribute

Student Student_ID StudentName

Professor Employee_ID ProfessorName

Course Course_ID CourseName

For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the sake of ease
we have considered just one attribute.
Step 5) Create the ERD
A more modern representation of ERD Diagram

Best Practices for Developing Effective ER Diagrams

 Eliminate any redundant entities or relationships
 You need to make sure that all your entities and relationships are properly labeled
 There may be various valid approaches to an ER diagram. You need to make sure that
the ER diagram supports all the data you need to store
 You should assure that each entity only appears a single time in the ER diagram
 Name every relationship, entity, and attribute are represented on your diagram
 Never connect relationships to each other
 You should use colors to highlight important portions of the ER diagram
Summary
 The ER model is a high-level data model diagram
 ER diagrams are a visual tool which is helpful to represent the ER model
 Entity relationship diagram displays the relationships of entity set stored in a database
 ER diagrams help you to define terms related to entity relationship modeling
 ER model is based on three basic concepts: Entities, Attributes & Relationships
 An entity can be place, person, object, event or a concept, which stores data in the
database
  Relationship is nothing but an association among two or more entities
 A weak entity is a type of entity which doesn't have its key attribute
 It is a single-valued property of either an entity-type or a relationship-type
 It helps you to defines the numerical attributes of the relationship between two entities
or entity sets
 ER- Diagram is a visual representation of data that describe how data is related to each
other
 While Drawing ER diagram you need to make sure all your entities and relationships
are properly labeled.

DBMS Generalization
Generalization is a process in which the common attributes of more than one entities form a
new entity. This newly formed entity is called generalized entity.
Generalization Example
Lets say we have two entities Student and Teacher.
Attributes of Entity Student are: Name, Address & Grade
Attributes of Entity Teacher are: Name, Address & Salary

The ER diagram before generalization looks like this:

These two entities have two common attributes: Name and Address, we can make a generalized
entity with these common attributes. Lets have a look at the ER model after generalization.
The ER diagram after generalization:
We have created a new generalized entity Person and this entity has the common attributes of
both the entities. As you can see in the following ER diagram that after the generalization
process the entities Student and Teacher only has the specialized attributes Grade and Salary
respectively and their common attributes (Name & Address) are now associated with a new
entity Person which is in the relationship with both the entities (Student & Teacher).

Note:
1. Generalization uses bottom-up approach where two or more lower level entities combine
together to form a higher level new entity.
2. The new generalized entity can further combine together with lower level entity to create a
further higher level generalized entity.

DBMS Specialization
Specialization is a process in which an entity is divided into sub-entities. You can think of it
as a reverse process of generalization, in generalization two entities combine together to form
a new higher level entity. Specialization is a top-down process.
The idea behind Specialization is to find the subsets of entities that have few distinguish
attributes. For example – Consider an entity employee which can be further classified as sub-
entities Technician, Engineer & Accountant because these sub entities have some distinguish
attributes.
Specialization Example
In this diagram, we can see that we have a higher level entity “Employee” which we have
divided in sub entities “Technician”, “Engineer” & “Accountant”. All of these are just an
employee of a company, however their role is completely different and they have few different
attributes. Just for the example, I have shown that Technician handles service requests,
Engineer works on a project and Accountant handles the credit & debit details. All of these
three employee types have few attributes common such as name & salary which we had left
associated with the parent entity “Employee” as shown in the above diagram.
 DBMS Aggregration
Aggregation is a process in which a single entity alone is not able to make sense in a
relationship so the relationship of two entities acts as one entity. I know it sounds confusing
but don’t worry the example we will take, will clear all the doubts.
Aggregration Example

In real world, we know that a manager not only manages the employee working under them
but he has to manage the project as well. In such scenario if entity “Manager” makes a
“manages” relationship with either “Employee” or “Project” entity alone then it will not make
 any sense because he has to manage both. In these cases the
relationship of two entities acts as one entity. In our example,
the relationship “Works-On” between “Employee” &
“Project” acts as one entity that has a relationship “Manages”
with the entity “Manager”.

Introduction of Relational Model

It was proposed by Dr. E.F. Codd. It uses the concept of relations to

represent each and every file. Relations are Two-Dimensional Tables. It is
easy to implement and easy to simplification in the operations to manipulate
the data. This is the most popular data model. It is simple to implement. It
uses the primary key and secondary key to connect any two files.
Normalization Theory is used to design the object-based data
model. Relational Algebra and Relational Calculus are used to process
the relations manually. Many database languages are oriented toward
handling relational data models. A Relational Database Model consists of
relations to connect them by key fields. A relation has some attributes. The
relation is represented in rows and columns. Each column of the relation is
called an attribute. Each row in the relation is called a tuple. Each relation
can have one unique column i.e. primary key. Each relation can have n-
columns and n-tuple. Each relation is preceded by the name of that relation.
The fields of the relations are separated by commas and placed within the
parentheses of the relation. The relational model represents data in the form
of relations or tables.

Example: Relational Model can be represented as shown below

STUDENT (StudNo, Sname, Special)

ENROLLMENT (StudNo, Subcode, marks)
SUBJECT (Subcode, Subname, Maxmarks, Faccode)
FACULTY (Faccode, Fname, Dept)

Terminologies

Relational Schema: Schema represents the structure of a relation.

Example: Relational Schema of STUDENT relation can be represented as

STUDENT(STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE,
STUD_COUNTRY, STUD_AGE).
Relational Instance: The set of values present in a relationship at a
particular instance of time is known as a relational instance as shown in
Table 1 and Table 2.
Attribute: Each relation is defined in terms of some properties, each of
which is known as an attribute.
Example: STUD_NO, STUD_NAME, etc. are attributes of relation
STUDENT.
The domain of an attribute: The possible values an attribute can take in a
relation is called its domain.
Example: domain of STUD_AGE can be from 18 to 40.
Tuple: Each row of a relation is known as a
tuple.
Example: STUDENT relation given below has 4 tuples.
NULL values: Values of some attribute for some tuples may be unknown,
missing, or undefined which are represented by NULL. Two NULL values in
a relationship are considered different from each other. Table 1 and Table 2
represent the relational model having two relations STUDENT and
STUDENT_COURSE.

STUDENT TABLE

STUD_ STUD_N STUD_PH STUD_ST STUD_COU STUD_

NO AME ONE ATE NTRY AGE

97162717
1 RAM Haryana India 20
21

98982912
2 RAM Punjab India 19
81

78982919
3 SUJIT Rajasthan India 18
81

99852863
4 SURESH Punjab India 21
17

STUDENT COURSE TABLE

STUD_NO COURSE_NO COURSE_NAME

1 C1 DBMS

2 C2 Computer Networks

1 C2 Computer Networks

Types of Keys in Relational Model

Keys are one of the basic requirements of a relational database

model. It is widely used to identify the tuples(rows) uniquely in the
table. We also use keys to set up relations amongst various columns
and tables of a relational database.
Different Types of Database Keys
 Candidate Key
  Primary Key
 Super Key
 Alternate Key
 Foreign Key
 Composite Key

Candidate Key

The minimal set of attributes that can uniquely identify a tuple is

known as a candidate key. For Example, STUD_NO in STUDENT
relation.
 It is a minimal super key.
 It is a super key with no repeated data is called a candidate
key.
 The minimal set of attributes that can uniquely identify a record.
 It must contain unique values.
 It can contain NULL values.
 Every table must have at least a single candidate key.
 A table can have multiple candidate keys but only one primary
key.
 The value of the Candidate Key is unique and may be null for a
tuple.
 There can be more than one candidate key in a relationship.

Example:
STUD_NO is the candidate key for relation STUDENT.

Table STUDENT

STUD_NO SNAME ADDRESS PHONE

1 Shyam Delhi 123456789

2 Rakesh Kolkata 223365796

3 Suraj Delhi 175468965

The candidate key can be simple (having only one attribute) or composite as
well.

Example:

{STUD_NO, COURSE_NO} is a composite

candidate key for relation STUDENT_COURSE.

Table STUDENT_COURSE
STUD_NO TEACHER_NO COURSE_NO

1 001 C001

2 056 C005

Primary Key

There can be more than one candidate key in relation out of which one can
be chosen as the primary key. For Example, STUD_NO, as well as
STUD_PHONE, are candidate keys for relation STUDENT but STUD_NO
can be chosen as the primary key (only one out of many candidate keys).
 It is a unique key.
 It can identify only one tuple (a record) at a time.
 It has no duplicate values, it has unique values.
 It cannot be NULL.
 Primary keys are not necessarily to be a single column; more than
one column can also be a primary key for a table.

Example:
STUDENT table -> Student(STUD_NO, SNAME,
ADDRESS, PHONE) , STUD_NO is a primary key
Table STUDENT
STUD_NO SNAME ADDRESS PHONE

1 Shyam Delhi 123456789

2 Rakesh Kolkata 223365796

3 Suraj Delhi 175468965

Super Key

The set of attributes that can uniquely identify a tuple is known as Super
Key. For Example, STUD_NO, (STUD_NO, STUD_NAME), etc. A super key
is a group of single or multiple keys that identifies rows in a table. It supports
NULL values.
 Adding zero or more attributes to the candidate key generates the
super key.
 A candidate key is a super key but vice versa is not true.
 Super Key values may also be NULL.

Example:

Consider the table shown above.

STUD_NO+PHONE is a super key.

 Relation between Primary Key, Candidate Key, and Super Key

Alternate Key

The candidate key other than the primary key is called an alternate key.
 All the keys which are not primary keys are called alternate keys.
 It is a secondary key.
 It contains two or more fields to identify two or more records.
 These values are repeated.
 Eg:- SNAME, and ADDRESS is Alternate keys

Example:
Consider the table shown above.
STUD_NO, as well as PHONE both,
are candidate keys for relation STUDENT but
PHONE will be an alternate key
(only one out of many candidate keys).

Primary Key, Candidate Key, and Alternate Key

Foreign Key
If an attribute can only take the values which are present as values of some other
attribute, it will be a foreign key to the attribute to which it refers. The relation
which is being referenced is called referenced relation and the corresponding
attribute is called referenced attribute the relation which refers to the referenced
relation is called referencing relation and the corresponding attribute is called
referencing attribute. The referenced attribute of the referenced relation should be
the primary key to it.
 It is a key it acts as a primary key in one table and it acts as
secondary key in another table.
 It combines two or more relations (tables) at a time.
 They act as a cross-reference between the tables.
 For example, DNO is a primary key in the DEPT table and a non-key in
EMP

Example:
Refer Table STUDENT shown above.
STUD_NO in STUDENT_COURSE is a
foreign key to STUD_NO in STUDENT relation.

Table STUDENT_COURSE

STUD_NO TEACHER_NO COURSE_NO

1 005 C001

2 056 C005

It may be worth noting that, unlike the Primary Key of any given relation, Foreign
Key can be NULL as well as may contain duplicate tuples i.e. it need not follow
uniqueness constraint. For Example, STUD_NO in the STUDENT_COURSE
relation is not unique. It has been repeated for the first and third tuples. However, the
STUD_NO in STUDENT relation is a primary key and it needs to be always unique,
and it cannot be null.
Composite Key

Sometimes, a table might not have a single column/attribute that uniquely identifies
all the records of a table. To uniquely identify rows of a table, a combination of two
or more columns/attributes can be used. It still can give duplicate values in rare
cases. So, we need to find the optimal set of attributes that can uniquely identify
rows in a table.
 It acts as a primary key if there is no primary key in a table
 Two or more attributes are used together to make a composite key.
 Different combinations of attributes may give different accuracy in terms of
identifying the rows uniquely.
Example:
FULLNAME + DOB can be combined
together to access the details of a student.

Different Types of Keys

Conclusion
In conclusion, the relational model makes use of a number of keys: Candidate keys
allow for distinct identification, the Primary key serves as the chosen identifier,
Alternate keys offer other choices, and Foreign keys create vital linkages that
guarantee data integrity between tables. The creation of strong and effective
relational databases requires the thoughtful application of these keys.
Many-to-Many M:N Relationship in DBMS

In a database management system, a Many-to-Many relationship is a

relationship between several instances of one entity and multiple instances
of another entity, i.e. both entities can have multiple relationships with each
other.

What is a Many-to-Many Relationship in DBMS?

This type of relationship exists when each of the records of the first
table can be associated with one or more records of the second table,
as well as a single record of the second table may be related to one or
more records of the first table. A Many-to-Many relationship is formed
by two one-to-many relationships that are connected by an ‘associate
table’ or ‘linking table.’ By having fields that are the primary keys of the
other two tables, the bridging table connects two tables. The following
example will help us comprehend this.

Example
When the entity types ‘Customer’ and ‘Product’ are combined, each
customer can purchase several products, and a product can be
purchased by multiple customers.

To grasp the concept of a linking table in this context, consider the ‘Order’
entity as a linking table that connects the ‘Customer’ and ‘Product’ entities.
This Many-to-Many relationship can be broken down into two one-to-many
partnerships. To begin with, each ‘Customer’ can have several ‘Orders,’
whereas each ‘Order’ is only associated with one ‘Customer.’ Second, each
‘Order’ is associated with only one Product, despite the fact that several
orders for the same Product may exist.
The concept of linking in the previous example can be understood by
considering all of the attributes of the entities ‘Order,’ ‘Customer,’ and
‘Product.’ The primary keys of both the ‘Product’ and ‘Customer’ entities are
included in the connecting table, i.e. the ‘Order’ table, as can be seen in the
above example. When referring to the respective table from the ‘Order’ table,
these keys operate as foreign keys.

Relational Algebra

Relational algebra is a procedural query language. It gives a step by

step process to obtain the result of the query. It uses operators to
perform queries.

Types of Relational operation

 1. Select Operation:

o The select operation selects tuples that satisfy a given predicate.

o It is denoted by sigma (σ).
1. Notation: σ p(r)
2.
Where:
σ is used for selection predication

r is used for relation

p is used as a propositional logic formula which may use connectors like: AND OR
and NOT. These relational can use as relational operators like =, ≠, ≥, <, >, ≤.

For example: LOAN Relation

BRANCH_NAME LOAN_NO AMOUNT

Downtown L-17 1000

Redwood L-23 2000

Perryride L-15 1500

Downtown L-14 1500

Mianus L-13 500

Roundhill L-11 900

Perryride L-16 1300

Input:
1. σ BRANCH_NAME="perryride" (LOAN)

Output:

BRANCH_NAME LOAN_NO AM
OUNT

Perryride L-15 1500

Perryride L-16 1300

2. Project Operation:

o This operation shows the list of those attributes that we wish to appear in the
result. Rest of the attributes are eliminated from the table.
o It is denoted by ∏.
1. Notation: ∏ A1, A2, An (r)
Where
A1, A2, A3 is used as an attribute name of relation r.

Example: CUSTOMER RELATION

NAME STREET CITY

Jones Main Harrison

Smith North Rye

Hays Main Harrison

Curry North Rye

Johnson Alma Brooklyn

Brooks Senator Brooklyn

Input:

1. ∏ NAME, CITY (CUSTOMER)

Output:

NAME CITY

Jones Harrison

Smith Rye

Hays Harrison

Curry Rye

Johnson Brooklyn

Brooks Brooklyn

3 Union Operation:

o Suppose there are two tuples R and S. The union operation contains all the
tuples that are either in R or S or both in R & S.
o It eliminates the duplicate tuples. It is denoted by ∪.
1. Notation: R ∪ S
A union operation must hold the following condition:
o R and S must have the attribute of the same number.
o Duplicate tuples are eliminated automatically.
Example:

DEPOSITOR RELATION

CUSTOMER_NAME ACCOU
NT_NO

Johnson A-101

Smith A-121

Mayes A-321

Turner A-176

Johnson A-273

Jones A-472

Lindsay A-284

BORROW RELATION

CUSTOMER_NAME LOAN_N
O

Jones L-17

Smith L-23

Hayes L-15

Jackson L-14

Curry L-93

Smith L-11

Williams L-17

Input:
1. ∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSI
TOR)
Output:

Johnson

Smith

Hayes

Turner

Jones

Lindsay

Jackson

Curry

Williams

Mayes

4. Set Intersection:

o Suppose there are two tuples R and S. The set intersection operation
contains all tuples that are in both R & S.
o It is denoted by intersection ∩.

1. Notation: R ∩ S
Example: Using the above DEPOSITOR table and BORROW table

Input:
1. ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSI
TOR)
Output:

CUSTOMER_NAME

Smith

Jones

5. Set Difference:

o Suppose there are two tuples R and S. The set intersection operation
contains all tuples that are in R but not in S.
o It is denoted by intersection minus (-).
 1. Notation: R - S

Example: Using the above DEPOSITOR table and BORROW table

Input:
1. ∏ CUSTOMER_NAME (BORROW) -
∏ CUSTOMER_NAME (DEPOSITOR)

Output:

CUSTOMER_NAME

Jackson

Hayes

Willians

Curry

6. Cartesian product

o The Cartesian product is used to combine each row in one table with each
row in the other table. It is also known as a cross product.
o It is denoted by X.
1. Notation: E X D

Example:

EMPLOYEE

EMP_ID EMP_NAME EMP_DEPT

1 Smith A

2 Harry C

3 John B

DEPARTMENT

DEPT_NO DEPT_NAME

A Marketing

B Sales

C Legal
Input:

1. EMPLOYEE X DEPARTMENT

Output:

EMP_ID EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME

1 Smith A A Marketing

1 Smith A B Sales

1 Smith A C Legal

2 Harry C A Marketing

2 Harry C B Sales

2 Harry C C Legal

3 John B A Marketing

3 John B B Sales

3 John B C Legal

7. Rename Operation:

The rename operation is used to rename the output relation. It is denoted by rho (ρ).
Example: We can use the rename operator to rename STUDENT relation to
STUDENT1.
1. ρ(STUDENT1, STUDENT)

Apart from these common operations Relational algebra can be used in

Join operations.

Join Operations:

A Join operation combines related tuples from different relations, if and only if a
given join condition is satisfied. It is denoted by ⋈.

Example:
EMPLOYEE

EMP_CODE EMP_NAME

101 Stephan

102 Jack

103 Harry

SALARY

EMP_CODE SALARY

101 50000

102 30000

103 25000

Operation: (EMPLOYEE ⋈ SALARY)

Result:

EMP_CODE EMP_NAME SALARY

101 Stephan 50000

102 Jack 30000

103 Harry 25000

Constraints on Relational Database Model

In modeling the design of the relational database we can put some restrictions like
what values are allowed to be inserted in the relation, and what kind of
modifications and deletions are allowed in the relation. These are the restrictions we
impose on the relational database.

In models like Entity-Relationship models, we did not have such features. Database
Constraints can be categorized into 3 main categories:
1. Constraints that are applied in the data model are called Implicit
Constraints.

2. Constraints that are directly applied in the schemas of the data model, by
specifying them in the DDL(Data Definition Language). These are
called Schema-Based Constraints or Explicit Constraints.
 3. Constraints that cannot be directly applied in the schemas of the data model.
We call these Application-based or Semantic Constraints.

So here we are going to deal with Implicit constraints.

Relational Constraints

These are the restrictions or sets of rules imposed on the database contents. It
validates the quality of the database. It validates the various operations like data
insertion, updation, and other processes that have to be performed without affecting
the integrity of the data. It protects us against threats/damages to the database.
Mainly Constraints on the relational database are of 4 types
 Domain constraints
 Key constraints or Uniqueness Constraints
 Entity Integrity constraints
 Referential integrity constraints

Types of Relational Constraints

Let’s discuss each of the above constraints in detail.

1. Domain Constraints
 Every domain must contain atomic values(smallest indivisible units) which
means composite and multi-valued attributes are not allowed.
 We perform a datatype check here, which means when we assign a data type
to a column we limit the values that it can contain. Eg. If we assign the
datatype of attribute age as int, we can’t give it values other than int
datatype.

Example:

EID Name Phone

123456789
01 Bikash Dutta
234456678
Explanation: In the above relation, Name is a composite attribute and Phone is a
multi-values attribute, so it is violating domain constraint.

2. Key Constraints or Uniqueness Constraints

 These are called uniqueness constraints since it ensures that every tuple in
the relation should be unique.
 A relation can have multiple keys or candidate keys(minimal superkey), out
of which we choose one of the keys as the primary key, we don’t have any
restriction on choosing the primary key out of candidate keys, but it is
suggested to go with the candidate key with less number of attributes.
 Null values are not allowed in the primary key, hence Not Null constraint is
also part of the key constraint.

Example:
EID Name Phone

01 Bikash 6000000009

02 Paul 9000090009

01 Tuhin 9234567892

Explanation: In the above table, EID is the primary key, and the first and the last
tuple have the same value in EID ie 01, so it is violating the key constraint.

3. Entity Integrity Constraints

 Entity Integrity constraints say that no primary key can take a NULL value,
since using the primary key we identify each tuple uniquely in a relation.
Example:
EID Name Phone

01 Bikash 9000900099

02 Paul 600000009

NULL Sony 9234567892

Explanation: In the above relation, EID is made the primary key, and the primary
key can’t take NULL values but in the third tuple, the primary key is null, so it is
violating Entity Integrity constraints.
 3. Referential Integrity Constraints

 The Referential integrity constraint is specified between two relations or

tables and used to maintain the consistency among the tuples in two
relations.

 This constraint is enforced through a foreign key, when an attribute in the

foreign key of relation R1 has the same domain(s) as the primary key of
relation R2, then the foreign key of R1 is said to reference or refer to the
primary key of relation R2.
 The values of the foreign key in a tuple of relation R1 can either take the
values of the primary key for some tuple in relation R2, or can take NULL
values, but can’t be empty.

Example:

EID Name DNO

01 Divine 12

02 Dino 22

04 Vivian 14

DNO Place

12 Jaipur

13 Mumbai

14 Delhi

Explanation: In the above tables, the DNO of Table 1 is the foreign key, and DNO
in Table 2 is the primary key. DNO = 22 in the foreign key of Table 1 is not allowed
because DNO = 22 is not defined in the primary key of table 2. Therefore,
Referential integrity constraints are violated here.

Conclusion

Relational database constraints are rules in a database model that help maintain the
integrity and consistency of data. These rules include primary key constraints,
unique constraints, foreign key constraints, check constraints, default constraints, not
null constraints, multi-column constraints, etc. Relational database constraints help
keep data accurate, maintain relationships, and avoid the insertion of wrong or
inconsistent data.