## Relational Calculus

Relational calculus is a non procedural query language. It uses mathematical predicate calculus instead of algebra. It provides the description about the query to get the result where as relational algebra gives the method to get the result. It informs the system what to do with the relation, but does not inform how to perform it.

For example, steps involved in listing all the students who attend ‘Database’ Course in relational algebra would be

- SELECT the tuples from COURSE relation with COURSE_NAME = ‘DATABASE’
- PROJECT the COURSE_ID from above result
- SELECT the tuples from STUDENT relation with COUSE_ID resulted above.

In the case of relational calculus, it is described as below:

Get all the details of the students such that each student have course as ‘Database’.

See the difference between relational algebra and relational calculus here. From the first one, we are clear on how to query and which relations to be queried. But the second tells what needs to be done to get the students with ‘database’ course. But it does tell us how we need to proceed to achieve this. Relational calculus is just the explanative way of telling the query.

There are two types of relational calculus – Tuple Relational Calculus (TRC) and Domain Relational Calculus (DRC).

## Tuple Relational Calculus

A tuple relational calculus is a non procedural query language which specifies to select the tuples in a relation. It can select the tuples with range of values or tuples for certain attribute values etc. The resulting relation can have one or more tuples. It is denoted as below:

**{t | P (t)} **or **{t | condition (t)} —** this is also known as expression of relational calculus

Where t is the resulting tuples, P(t) is the condition used to fetch t.

**{t | EMPLOYEE (t) and t.SALARY>10000}** – implies that it selects the tuples from EMPLOYEE relation such that resulting employee tuples will have salary greater than 10000. It is example of selecting a range of values.

**{t | EMPLOYEE (t) AND t.DEPT_ID = 10}** – this select all the tuples of employee name who work for Department 10.

The variable which is used in the condition is called **tuple variable**. In above example t.SALARY and t.DEPT_ID are tuple variables. In the first example above, we have specified the condition t.SALARY >10000. What is the meaning of it? For all the SALARY>10000, display the employees. Here the SALARY is called as bound variable. Any tuple variable with ‘*For All’* (?) or ‘*there exists’* (_{?}) condition is **called bound variable**. Here, for any range of values of SALARY greater than 10000, the meaning of the condition remains the same. Bound variables are those ranges of tuple variables whose meaning will not change if the tuple variable is replaced by another tuple variable.

In the second example, we have used DEPT_ID= 10. That means only for DEPT_ID = 10 display employee details. Such variable is called free variable. Any tuple variable without any ‘*For All’* or ‘*there exists’* condition is called **Free Variable**. If we change DEPT_ID in this condition to some other variable, say EMP_ID, the meaning of the query changes. For example, if we change EMP_ID = 10, then above it will result in different result set. Free variables are those ranges of tuple variables whose meaning will change if the tuple variable is replaced by another tuple variable.

All the conditions used in the tuple expression are called as well formed formula – WFF. All the conditions in the expression are combined by using logical operators like AND, OR and NOT, and qualifiers like ‘For All’ (?) or ‘there exists’ (?). If the tuple variables are all bound variables in a WFF is called **closed WFF**. In an **open WFF**, we will have at least one free variable.

## Domain Relational Calculus

In contrast to tuple relational calculus, domain relational calculus uses list of attribute to be selected from the relation based on the condition. It is same as TRC, but differs by selecting the attributes rather than selecting whole tuples. It is denoted as below:

{< a_{1}, a_{2}, a_{3}, … a_{n} > | P(a_{1}, a_{2}, a_{3}, … a_{n})}

Where a_{1}, a_{2}, a_{3}, … a_{n} are attributes of the relation and P is the condition.

For example, select EMP_ID and EMP_NAME of employees who work for department 10

**{<EMP_ID, EMP_NAME> | <EMP_ID,** **EMP_NAME> ****? EMPLOYEE Λ DEPT_ID = 10}**

Get name of the department name that Alex works for.

**{DEPT_NAME |< DEPT_NAME > ****? DEPT ****Λ ?**** DEPT_ID (<DEPT_ID> ****? EMPLOYEE Λ EMP_NAME = Alex)}**

Here green color expression is evaluated to get the department Id of Alex and then it is used to get the department name form DEPT relation.

Let us consider another example where select EMP_ID, EMP_NAME and ADDRESS the employees from the department where Alex works. What will be done here?

**{<EMP_ID, EMP_NAME, ADDRESS, DEPT_ID > |**** <EMP_ID, EMP_NAME, ADDRESS, DEPT_ID> ****? EMPLOYEE ****Λ ?**** DEPT_ID (<DEPT_ID> ****? EMPLOYEE Λ EMP_NAME = Alex)}**

First, formula is evaluated to get the department ID of Alex (green color), and then all the employees with that department is searched (red color).

Other concepts of TRC like free variable, bound variable, WFF etc remains same in DRC too. Its only difference is DRC is based on attributes of relation.