UNIT – II

Relational Model: Introduction to the Relational Model, Integrity Constraints over Relations,
Enforcing Integrity Constraints, Querying Relational Data, Logical Database Design: ER to
Relational, Introduction to Views, Destroying/Altering Tables and Views
Relational Algebra: Selection and Projection, Set Operations, Renaming, Joins,Division, More
Examples of Algebra Queries
Relational Calculus: Tuple Relational Calculus, Domain Relational Calculus
__________________________________________________________________________________
2.1 Introduction to the Relational Model
Relational Model was proposed by E.F. Codd to model data in the form of relations or tables.
After designing the conceptual model of Database using ER diagram, we need to convert the
conceptual model in the relational model which can be implemented using any RDBMS
languages like Oracle SQL, MySQL etc.
Relational Model represents how data is stored in Relational Databases.
A relational database stores data in the form of relations (tables). Consider a relation STUDENT
with attributes
Roll Number,Name,CGPA shown in Table.

• A relation is the fundamental structure used in the relational model to store data. It is
conceptually represented as a table with rows (tuples) and columns (attributes or fields).
• A relation consists of
1.Relation Schema.
2.Relation Instance.
Relation Schema vs Relation Instance:
• 1.Relation Schema:
The schema species the relation's name, the name of each field names (or column, or
attribute), and the domain(data type) of each field.
 A domain (data type). is referred to in a relation schema by the domain name and has a set
of associated values.
Example: We use the example of student information in a university database to show
relation schema as
Students(sid: string, name: string, login: string, age: integer, gpa: real).
for instance, that the field named sid has a domain named string.
This schema shows that the relation "Students" has five fields, each with its domain
2.Relation Instance:
An instance of a relation is a set of tuples, also called records, in which each tuple has the
same number of fields as the relation schema .
A relation instance can be thought of as a table in which each tuple is a row, and all rows
have the same number of fields.
Represents the actual data in the relation at a specific moment
Example of a tuple:
<sid: 50000, name: Dave, login: dave@cs, age: 19, gpa: 3.3>
Key Characteristics of the Relational Model:
1.Uniqueness of Tuples:
No two rows (tuples) in a relation can be identical. This ensures that each tuple is unique.
2.Order Irrelevance:
The order of tuples (rows) does not matter.
Similarly, the order of fields (columns) is irrelevant unless the database system explicitly
defines a convention for ordering fields
3.Domain Constraints:
Each attribute is associated with a domain that restricts the values it can hold.
Domain constraints ensure that the values in each column adhere to their data type.
• Example: If "age" has the integer domain, only whole numbers are allowed in that
column.
Formal Notation for a Relation Instances:A relation schema can be expressed as:
R(f1: D1, ..., fn: Dn) .Each field fi has an associated domain Di,each tuple in an instance of R
must satisfy these domain constraints

 Example set of tuples:{ <f1: d1, ..., fn: dn> | d1 ∈ Dom1, ..., dn ∈ Domn }
Angular brackets <……> identify fields of a tuple.

 EX:<sid: 50000, name: Dave, login: dave@cs, age: 19, gpa: 3.3>-------------
-Tuple
 Curly brackets { : : : } denote a set of tuples. {<>,<>,<>……}
 The vertical bar ( | ) means “such that,” and ∈ indicates that values belong to a
specific domain.
Key Terminology of Relation:
1.Arity (Degree):
• The degree, also called arity, of a relation is the number of fields.
• Example: The "Students" relation has 5 columns (sid, name, login, age, gpa).
2.Cardinality:
• The number of tuples (rows) in a relation instance is called Cardinality.
• Example: If the relation contains 6 rows, its cardinality is 6.

.
 3.Relational Database:A collection of relations with distinct relation names.
The following Relations:
1. Students2. Faculty3. Courses4. Rooms5. Enrolled6. Teaches7. MeetsIN are considered as
example for relational database
4.Relational Database Schema: A collection of relation schemas for all the relations in the
database
Example: University Database
5.Relational Database Instance: A collection of relation instances, one for each relation schema,
representing the current state of the database.
Examples

2.1.1 Creating and Modifying Relations Using SQL-92

SQL-92 and DDL Overview
• SQL-92 Language Standard: Uses the term "table" to refer to a "relation.“
• Data Definition Language (DDL): Subset of SQL used for creating, deleting, and modifying
tables
• Built-in Types: Discussed examples include CHAR, INTEGER, and REAL

SQL Commands:
1.CREATE TABLE: statement is used to define a new table
• To create the Students relation, we can use the following statement:
2. INSERT:
• Tuples are inserted using the INSERT command. Add new tuples (rows) to a table.
• We can insert a single tuple into the Students table as follows:

3. DELETE:
• We can delete tuples from a table using the DELETE command.
• We can delete all Students tuples with name equal to Smith using the command:

4. UPDATE:
• Modify the column values in an existing rows in a table.
• For example, we can increment the age and decrement the gpa of the student with sid :53688:

The WHERE clause is applied first and determines which rows are to be modied
• The SET clause specifies how to modify the filtered rows.
• If modifying a column's value based on its current state, the old value is used in the
calculation
Example of Update with Condition:
UPDATE Students S SET S.gpa = S.gpa - 0.1 WHERE S.gpa >= 3.3;
If this query is applied on the instance S1 of Students we obtain the instance as follows:
2.2 INTEGRITY CONSTRAINTS OVER RELATIONS
• A database is only as good as the information stored in it, and a DBMS must therefore help
prevent the entry of incorrect information.
• Integrity Constraint:An integrity constraint (IC) is a condition that is specified on a
database schema, and restricts the data that can be stored in an instance of the database.
• EXAMPLE- A brood group must be ‘A’ or ‘B’ or ‘AB’ or ‘O’ only (can not any other values
else).
• Constraints may apply to each attribute or they may apply to relationships between tables.
• If a database instance satisfies all the integrity constraints specified on the database
schema, it is a legal instance.
• A DBMS enforces integrity constraints, in that it permits only legal instances to be stored in
the database.
INTEGRITY CONSTRAINTS OVER RELATIONS
• 2.2.1. Key Constraints
-Specifying key constraints in SQL
• 2.2.2. Foreign Key Constraints
-Specifying Foreign key constraints in SQL
• 2.2.3. General Constraints
Types of Integrity Constraint:

• Integrity Constraints Specification and Enforcement:

Integrity constraints are specified and enforced at different times:
 • Schema Definition: The DBA or end user specifies ICs when defining the database schema.
• Application Execution: The DBMS checks for violations during application runs and
disallows non-compliant data changes.

2.2.1 Key Constraints

• A key constraint is a statement that a certain minimal subset of the fields of a relation is a
unique identifier for a tuple .
The types of key constraints-
1. Primary key constraints
2. Unique key constraints
3. Foreign Key constraints
4. NOT NULL constraints
5. Check constraints

A set of fields that uniquely identifies a tuple according to a key constraint is called a
candidate key for the relation

• A candidate key (or key) is such a unique set of fields, e.g., sid in the Students relation.
• Two or more columns can be combined together to retrieve data uniquely:Candidate Key
EX: {login, age}

Key constraints have two rules:

1. No two distinct tuples can have identical values in all key fields.
2. No subset of a key can uniquely identify a tuple.
 A relation can have multiple candidate keys, such as {login, age} in the Students relation
may, taken together, also identify students uniquely
 Though login alone may seem unique in one instance, keys must guarantee uniqueness across
all legal instances
 Declaring {login, age} as a key means no two students can share both the same login and age
1. Super Key − A set of attributes (one or more) that collectively identifies an entity in an entity set.
2. Candidate Key − A minimal super key is called a candidate key. An entity set may have more than
one candidate key.
3. Primary Key − A primary key is one of the candidate keys chosen by the database designer to
uniquely identify the entity set

Specifying Key Constraints in SQL-92

• In SQL we can declare that a subset of the columns of a table constitute a key by using the
UNIQUE constraint.
• At most one of these "candidate" keys can be declared to be a primary key, using the
PRIMARY KEY constraint

In the given SQL query,StudentsKey is the name of the primary key constraint.
PRIMARY KEY (sid): Specifies that the sid column is the primary key.
CONSTRAINT keyword: Allows assigning a name to the constraint.
If the constraint is violated, the constraint name is returned and can be used to identify the error.

2.2.2 Foreign Key Constraints

 The information stored in a relation is linked to the information stored in another

relation.
 Foreign keys ensure data consistency between related tables by linking fields in one
table to primary keys in another..
 An IC involving both relations must be specified if a DBMS is to make such checks.
 The most common IC involving two relations is a foreign key constraint .
 Any changes in one table may require checks or modifications in the linked table to
maintain consistency
 Used to link two tables via Primary Key
 For example, in the Students and Enrolled tables, the sid in Enrolled must match a sid
in Students.
Ex:1

Ex2:

If an inserted sid in Enrolled does not exist in Students, or if a sid in Students is

deleted but still referenced in Enrolled, the DBMS enforces consistency by rejecting
or adjusting the change.
A foreign key can also refer to the same table, such as a "partner" field in Students
referencing another sid in the same table.
Foreign keys can be null if no match is present, but primary keys cannot be null, as they
uniquely identify rows

Specifying Foreign Key Constraints in SQL-92

• Let us define Enrolled(sid: string, cid: string, grade: string):

 • The foreign key constraint requires that each sid in Enrolled must also exist in Students,
meaning sid in Enrolled references Students.
• The primary key constraint ensures that each student has only one grade per course.
• If multiple grades per student per course are needed, the primary key constraint should be
adjusted.
• The following rules has to be considered for Referential integrity constraints:

2.2.3 General Constraints

• Domain, primary key, and foreign key constraints are fundamental to the relational model, but
more general constraints are sometimes needed.
• Additional constraints, like setting an age range for students, prevent data entry errors.
• For example, we may restrict student ages to a certain range.
• If students must be at least 16 years old, the instance in Figure becomes illegal because two
students are underage.

Specifying General constraints:

• Disallowing these tuples results in a legal instance

 This age constraint acts as an extended domain constraint, setting stricter rules than
standard domains like integer.
 Beyond domain, key, or foreign key constraints, more complex rules can be applied—for
example, requiring students over 18 to have a GPA above 3.
Relational databases support these rules via table constraints (checked on single table
modifications) and
 assertions several tables and are checked whenever any of these tables is modified.
Both table constraints and assertions use SQL queries to define and enforce restrictions.

2.3 ENFORCING INTEGRITY CONSTRAINTS

• ICs are specified when a relation is created and enforced when a relation is modified.
• · The impact of domain, PRIMARY KEY, and UNIQUE constraints is straightforward: if an
insert, delete, or update command causes a violation, it is rejected.
• .

• A similar problem arises whenever we try to insert a tuple with a value in a field that is not in
the domain associated with that field, i.e., whenever we violate a domain constraint.
• Deletion does not cause a violation of domain, primary key or unique constraints. However,
an update can cause violations, similar to an insertion
2.4. QUERYING RELATIONAL DATA
• A relational database query (query, for short) is a question about the data, and the answer
consists of a new relation containing the result. For example, we might want to find all
students younger than 18 or all students enrolled in Reggae203.
• · A query language is a specialized language for writing queries.
• · SQL is the most popular commercial query language for a relational DBMS.
• To selecting a subset of tuples, a query can extract a subset of the fields of each selected
tuple.
• We can compute the names and logins of students who are younger than 18 with the
following query:
• SELECT S.name, S.login FROM Students S WHERE S.age < 18;

• The symbol * means that we retain all fields of selected tuples in the result
• SELECT * FROM Students WHERE age < 18;
• We can also combine information in the Students and Enrolled relations. If we want to obtain
the names of all students who obtained an A and the id of the course in which they got an A,
we could write the following query:
• SELECT S.name, E.cid
FROM Students S, Enrolled E WHERE S.sid = E.sid AND E.grade = ‘A’

DISTINCT(different) Types in SQL

In SQL, comparing values from different domains should fail, even if they are compatible
(e.g., both numeric or string).
For example, comparing
salary and age (both integers) should be invalid,
but in SQL-92, a comparison like
S < A will succeed (e.g., 25 < 50).
SQL:1999 solves this by introducing DISTINCT types, allowing salary and age to be treated
as distinct even if both use integers.
Systems like Informix UDS and IBM DB2 already support this feature.
2.5. LOGICAL DATABASE DESIGN: ER TO RELATIONAL
2.5.1. Entity Sets to Tables
2.5.2. Relationship Sets (without Constraints) to Tables
2.5.3. Translating Relationship Sets with Key Constraints
2.5.4. Translating Relationship Sets with Participation Constraints
2.5.5. Translating Weak Entity Sets
2.5.6. Translating Class Hierarchies
2.5.7. Translating ER Diagrams with Aggregation
2.5.8. ER to Relational: Additional Examples

LOGICAL DATABASE DESIGN: ER TO RELATIONAL

• The ER model is convenient for representing an initial, high-level database design.
• · An ER diagram describing a database, there is a standard approach to generating a relational
database schema that closely approximates the ER design.
• · We now describe how to translate an ER diagram into a collection of tables with
associated constraints, i.e., a relational database schema
2.5.1.Entity Sets to Tables
• An entity set is mapped to a relation in a straightforward way: Each attribute of the entity set
becomes an attribute of the table.
• · Consider the Employees entity set with attributes ssn, name, and lot as shown below
• The following SQL statement captures the preceding information, including the domain
constraints and key information:
2.5.2. Relationship Sets (without Constraints) to Tables
• A relationship set, like an entity set, is mapped to a relation in the relational model.
• To represent a relationship set into a table we have to identify participating entities and
descriptive attributes of the relationship.
• Thus, the attributes of the relation include:

 The primary key attributes of each participating entity set, as foreign key
fields.
 The descriptive attributes of the relationship set.
• The set of non-descriptive attributes is a superkey for the relation. If there are no key
constraints, this set of attributes is a candidate key

Consider a relationship report, as shown below: This relationship set can be converted to a table as
follow
2.5.3. Translating Relationship Sets with Key Constraints
• If a relationship set involves n entity sets and some m of them are linked via arrows in the ER
diagram, the key for any one of these m entity sets constitutes a key for the relation to which
the relationship set is mapped.
• · Thus we have m candidate keys, and one of these should be designated as the primary key.
• · Consider the relationship set Manages shown in below. The table corresponding Manages
has ssn, did, since.
Approach 1: (creating separate table for relationship)
• By this approach the relationship associated with more than one entities is separately
represented using a table. For example - Consider following ER diagram. Each Dept has at
most one manager, according to the key constraint on Manages.
• The table for manages relationship consists of attributes ssn, did, since.did as primary keyand
ssn, did becomes foreign key
Now this relationship consists of three tables Employee, Department and Manages.
Approach 2:No separate table for relationship
• A second approach to translating a relationship set with key constraints is often superior
because it avoids creating a distinct table for the relationship set.
• Modify the table which corresponds to primary key inabove relation(i.e;didof department) by
adding key field of employee and descriptiveattribute “since”.

2.5.4. Translating Relationship Sets with Participation Constraints

•
Every department is required to have a manager, due to the participation constraint, and at
most one manager, due to the key constraint
• This relationship set can be converted to a table as;
The NO ACTION specification is the default it tells that ssn employee can’t be deleted if it is pointed
by the Dept_Mgr table
2.5.5. Translating Weak Entity Sets
• A weak entity set always participates in a one-to-many binary relationship and has a key
constraint and total participation at a weak entity
• Consider the following ER diagramof weak entity

The weak entity can’t be uniquely identified by its partial key, so it should be combined with
the primary key of owning entity to form the primary key of the relationship. This relation can
be written as:

The cascade option ensures that information about the policy is deleted if the employee tuple
is deleted.

2.5.6. Translating Class Hierarchies

Method 1: Map each entity set (Employees, Hourly Emps, Contract Emps) to separate tables.
 Attributes of subclasses (e.g., hourly_wages, hours_worked) and superclass keys (e.g., ssn)
are included.
 Example:
o Employees(ssn, name, lot)
o Hourly_Emps(ssn, hourly_wages, hours_worked)
o Contract_Emps(ssn, contractid)
Method 2: Map only subclasses to tables, duplicating superclass attributes in each subclass.
 Example:
o Hourly_Emps(ssn, hourly_wages, hours_worked)
o Contract_Emps(ssn, contractid)
Method 3: Map only the superclass to a table, including all subclass attributes.
 Example:
o Employee(ssn, name, lot, hourly_wages, hours_worked, contractid)

2.5.7. Translating ER Diagrams with Aggregation

 Translating aggregation into the relational model is straightforward as entities and

relationships are treated similarly.
 The Sponsors relation (with attributes pid, did, since) is needed when:

• Descriptive attributes like since must be recorded.

• Some <pid, did> pairs in Sponsors don't appear in Monitors.
•  If Sponsors has no descriptive attributes and full participation in Monitors, its data
can be derived from Monitors, eliminating the need to store Sponsors..
2.6. INTRODUCTION TO VIEWS
• 2.6.1. Views, Data Independence, Security
• 2.6.2. Updates on Views
• VIEW: (Virtual table)A view is a table whose rows are not explicitly stored, a view is a
virtual table based on the result-set of an SQL statement.
A view can contain all rows of a table or select rows from a table.
• A view can be created from one or many tables which depends on the written SQL query to
create a view.
• Simply a view is nothing but a stored SQL Query

1.Creating Views

Example of view-simple view

2.Inserting a row in a view
We can insert a row in a View in a same way as we do in a table. We can use the INSERT INTO
statement of SQL to insert a row in a View.
Syntax:
INSERT INTO view_name(column1, column2, ...)
VALUES(value1,value2,.....);
EX: INSERT INTO DetailsView(NAME,ADDRESS) VALUES(“Suresh”,”Gurgaon”)
SELECT * FROM DetailsView;
3.Deleting a row in a view
Deleting rows from a view is also as simple as deleting rows from a table. We can use the DELETE
statement of SQL to delete rows from a view.
Syntax:
DELETE FROM view_name WHERE condition;
EX:
DELETE FROM DetailsView WHERE NAME=”Suresh”;
SELECT * FROM DetailsView;

2.6.1. Views, Data Independence, Security

• · The physical schema for a relational database describes how the relations in the conceptual
schema are stored, in terms of the file organizations and indexes used.
• Views in the external schema provide logical data independence by masking changes.
• Example: A view can preserve an old schema for application compatibility..
• · For example, if the schema of a stored relation is changed, we can define a view with the old
schema, and applications that expect to see the old schema can now use this view

2.6.2 Updates on Views

• The motivation behind the view mechanism is to tailor how users see the data.
• Users should not have to worry about the view versus base table distinction.
• This goal is indeed achieved in the case of queries on views; a view can be used just like any
other relation in defining a query. However, it is natural to want to specify updates on views
as well.
• Here, unfortunately, the distinction between a view and a base table must be kept in mind.
• An update on such a restricted view can always be implemented by updating the underlying
base table in an unambiguous way. Consider the following view:
Syntax for updating Views:

•
We can implement a command to modify the gpa of a GoodStudents row by modifying the
corresponding row in Students. We can delete a GoodStudents row by deleting the
corresponding row from Students.
• Need to Restrict View Updates
• · The SQL-92 rules on updatable views are more stringent than necessary, there are some
fundamental problems with updates specified on views, and there is good reason to limit the
class of views that can be updated. Consider the Students relation and a new relation called
Clubs:
• · A tuple in Clubs denotes that the student called mname has been a member of the club
cname since the date jyear 4 Suppose that we are often interested in finding the names and
logins of students with a gpa greater than 3 who belong to at least one club, along with the
club name and the date they joined the club. We can define a view for this purpose:

2.7 DESTROYING/ALTERING TABLES AND VIEWS

• If we decide that we no longer need a base table and want to destroy it (i.e., delete all the rows
and remove the table definition information), we can use the DROP TABLE command.
For example, DROP TABLE Students RESTRICT destroys the Students table unless some
view or integrity constraint refers to Students; if so, the command fails.
 • If the keyword RESTRICT is replaced by CASCADE, Students is dropped and any
referencing views or integrity constraints are (recursively) dropped as well; one of these two
keywords must always be specified.
• A view can be dropped using the DROP VIEW command, which is just like DROP TABLE.
• ALTER TABLE modifies the structure of an existing table. To add a column called maiden-
name to Students, for example, we would use the following command:
Syntax:
DROP VIEW VIEW_NAME;

ALTER:

The definition of Students is modified to add this column, and all existing rows are padded
with null values in this column
ALTER TABLE can also be used to delete columns and to add or drop integrity constraints
on a table; we will not discuss these aspects of the command beyond remarking that dropping
columns is treated very similarly to dropping tables or views

2.8 Relational Algebra

• Query Language
• In simple words, a Language which is used to store and retrieve data from database is known
as query language. For example – SQL
• There are two types of query language:
1.Procedural Query language
2.Non-procedural query language

Procedural Query Language:

 Users specify what data to retrieve and how to retrieve it by providing a sequence of
operations.
 Examples: BASIC, FORTRAN

Non-Procedural Query Language:

 Users specify what data to retrieve but not how to retrieve it; the system determines the
process.
  Examples: SQL, PROLOG, LISP

Relational Algebra
• There are two formal query languages associated with relational model and those are
relational algebra and relational calculus.

• Relational Algebra can be simply called as Algebra. Queries in algebra are composed
using a collection of operators.
• Every operator in the algebra accepts (one or two) relation instances as arguments and
returns a relation instance as the result.
• A relation on the operator is called as relational algebra expression.
• Unary operators take one expression, and binary operators will take two expressions.
 1. Selection(σ) : operators used to select rows from a relation where the given condition is
satisfied is called Selection operator

syntax:

EX: We can retrieve rows corresponding to expert sailors by using the σ operator. The
expression

The subscript rating>8 specifies the selection criterion to be applied while retrieving tuples.
output:

The selection operator “σ”specifies the tuples to return through a selection condition.
Selection condition will be in the form of attribute op constant orattribute1opattribute.
op is one of the comparisonoperator from <,>, <=, >=, or =.
 2. Projection Operation (∏):
The projection operator(π) allows to extract columns from a relation.

For example,we can get all Sailor names and rating from s2 by using π as follows
EX:

It will return the following relation.

πage(S2) returns

Since the output of a query is also a relation, we can write the query as follows.

It produces the result by applying selection on S2, and applying projection on output relation.
The final output is as follows.

3.Set operations:
Thefollowing standard operations on sets are also available in relation algebra:

1.union(∪)
2.intersection(∩),
3.set-difference(−),and
4.cross-product(×).
1. Union Operation (∪): It performs union operation between two given relations. It
combines rows from two given relations.
Notation: r U s
EX:

2. Intersection Operation (∩): It performs intersection operation between two given

relations . It collect only rows which are common in the two given relations.

Notation: R ∩ S

3. Set Difference (−): It finds tuples which are present in one relation but not in the second

relation.

Notation: r − s
4.Cross –Product:R X S returns a relation instance that contain all fields of R followed by all the
fields of S
The result of R X S, contains one tuples(r, s)for each pair r ∈ R, s ∈ S. This operation is also called as
Cartesian product.
Ex:

RxS

4.Rename Operation (ρ):

The results of relational algebra are also relations but without any name. The rename operation allows
us to rename the output relation. 'rename' operation is denoted with small Greek letter rho ρ.

The renaming operator(ρ) is used for change exist name.

Where the result of expression E is saved with name of x.

ρ (a/b)R will rename the attribute ‘b’ of relation by ‘a’.
Example: We can use the rename operator to rename STUDENT relation to STUDENT1.
1. ρ(STUDENT1, STUDENT)
5.Joins:
The join operation is one of the most useful operations in relational algebra and is the most commonly
used way to combine information from two or more relations.
Join can be defined as a cross-product followed by selections and projections.
There are mainly two types of joins in DBMS:
1. Inner Joins: Theta, Natural, EQUI
2. Outer Join: Left, Right, Full
1.Inner Join is used to return rows from both tables which satisfy the given condition. It is the
most widely used join operation and can be considered as a default join-type

Inner Join further divided into three subtypes:

 Theta join/Conditional join

 EQUI join
 Natural join

i)Theta Join:
allows you to merge two tables based on the condition It is denoted by symbol θ..
• Theta joins work for all comparison operators

• Syntax:
A ⋈θ B
The operation is defined as

ii).Equijoin:

When Theta join uses only equality comparison operator, it is said to be equijoin. The above example
corresponds to equijoin
. For example, the condition for equi join can be R.name1 = S.name2, that is, equalities between two
fields in R and S.
The schema of the result of an equijoin contains the fields of R (with the same names and domains as
in R) followed by the fields of S that do not appear in the join conditions. If this set of fields in the
result relation includes two fields that inherit the same name from R and S, they are unnamed in the
result relation
Ex:

iii) Natural Join

A further special case of the join operation R S is an equijoin in which equalities are specified on
all fields having the same name in R and S

In this case, we can simply omit the join condition; the default is that the join condition is a collection
of equalities on all common fields.

e)Division(/):
The division operator is used for queries which involve the 'all'.
R1 ÷ R2 = tuples of R1 associated with all tuples of R2.
The resulting operation must have all combinations of tuples of relation S that are present in the first
relation or R.
2.9 Relational Calculus
Relational calculus is an alternative to relational algebra. In contrast to the algebra, which
is procedural, the calculus is nonprocedural, or declarative, in that it allows us to describe
the set of answers without being explicit about how they should be computed

• Relational Calculus is of Two Types:

1. Tuple Relational Calculus (TRC)
2. Domain Relational Calculus (DRC)
EX:
Ex2:
Example:
Suppose we have an EMPLOYEE table with EMP_ID, NAME, and SALARY attributes. We want to
retrieve the names of employees who earn a salary greater than 50,000.

TRC Query:
{T.NAME | EMPLOYEE(T) AND T.SALARY > 50,000}
Result:
NAME
Alice
Charlie
This query fetches the names of employees earning more than 50,000 from the EMPLOYEE table

Using Quantifiers in TRC

TRC allows the use of Existential (∃) and Universal (∀) quantifiers to refine queries further.
Example:
We can use quantifiers to find employees who earn more than 50,000 and also work in
the HR department. Suppose we add a DEPARTMENT column to our EMPLOYEE table:
EMP_ID NAMESALARYDEPARTMENT
101 Alice 60,000 HR
102 Bob 45,000 IT
103 Charlie 55,000 HR

TRC Query:
{T.NAME | ∃T ∈ EMPLOYEE (T.SALARY > 50,000 AND T.DEPARTMENT = 'HR')}
Result:
NAME
Alice
Charlie
This query retrieves the names of employees in the HR department who earn more than 50,000.
2. Domain Relational Calculus (DRC)
2.Domain Relational Calculus (DRC) is another type of non-procedural query language. Instead of
working with tuples, DRC works with individual attribute values.
In DRC, conditions are applied to domains (i.e., attributes of the table), and the result consists of
specific attributes that satisfy those conditions.

Notation:

A query in DRC is expressed as:

{a1, a2, a3, ..., an | P(a1, a2, a3, ..., an)}

• a1, a2, ... are attributes of the relation.
• P represents the condition or predicate applied to the attributes .
• When using relational calculus, two common quantifiers are often employed:
1. Universal Quantifier ( ∀ ): This means "for all." It indicates that all tuples in a given set must
satisfy a particular condition.
2. Existential Quantifier ( ∃ ): This means "there exists." It shows that at least one tuple in the
given set satisfies the specified condition.

An atomic formula in DRC is one of the following:

(x1, x2, . . . , xn) ∈ Rel, where Rel is a relation with n attributes; each xi, 1 ≤ i ≤
n is either a variable or a constant
X op Y
X op constant, or constant op X
A formula is recursively defined to be one of the following, where P and q are
themselves formulas and p(X) denotes a formula in which the variable X appears:
any atomic formula
┐p, P /\ q, P V q, or p => q
∃X(p(X)), where X is a domain variable
∀ X(p(X)), where X is a domain variable

Example:

Consider the same EMPLOYEE table. Now, let’s write a DRC query to find
the EMP_ID and NAME of employees who earn a salary greater than 50,000.
DRC Query:
{EMP_ID, NAME | EMPLOYEE(EMP_ID, NAME, SALARY) AND SALARY > 50,000}
Result:
EMP_ID NAME
101 Alice
103 Charlie

This query returns the EMP_ID and NAME of employees whose salary exceeds 50,000.
Using Quantifiers in DRC
Similar to TRC, DRC also supports Existential (∃) and Universal (∀) quantifiers to
refine queries.
Example:
Let’s say we want to find employees who earn more than 50,000 and work in
the HR department. Using quantifiers, we can achieve this as follows:
DRC Query:
{EMP_ID, NAME | ∃(EMP_ID, NAME, SALARY, DEPARTMENT) ∈
EMPLOYEE (SALARY > 50,000 AND DEPARTMENT = 'HR')}
Result:
EMP_ID NAME
101 Alice
103 Charlie