Tuple and Domain Relational Calculus in DBMS

Introduction

A database query can describe the operations needed to produce a result or specify the conditions that the result must satisfy. Relational calculus follows the second approach: it expresses requirements using logical conditions, without prescribing an evaluation procedure.

Tuple Relational Calculus and Domain Relational Calculus are its two main forms. Both describe database queries through predicates and variables, but they differ in what those variables represent. Understanding this distinction helps connect relational theory with SQL filtering, joins, and existence checks.

What Is Relational Calculus?

Relational calculus is a declarative, or non-procedural, formal query language based on first-order predicate logic. A query specifies the properties of the required result rather than a sequence of relational operations.

Conditions describe which data qualifies for the result. The database system determines how to retrieve that data; the calculus expression does not prescribe a physical execution plan.

Its two forms are:

• Tuple Relational Calculus (TRC): Variables represent tuples, or rows.

• Domain Relational Calculus (DRC): Variables represent individual attribute values.

Here, a domain means a set of possible values for an attribute, such as integers or text values.

Example Relations

Consider a college database containing two relations. Student stores student details and department membership, while Department stores department identifiers and names.

Student : initial data

Department : initial data

Assume that StudentID is the primary key of Student, and DeptID is the primary key of Department. A student’s DeptID identifies their department. Mathematics has no students in the displayed data.

Using these relations, a query requirement might be:

Find students whose semester is 2 and whose department appears in the Department relation.

Asha and Meera satisfy both conditions: each is in semester 2, and their department identifier, 10, appears in Department. Ravi does not qualify because his semester is 4.

Relational calculus expresses these conditions without specifying which relation should be scanned first or which physical join algorithm should be used. The same relations will support the TRC and DRC examples that follow.

Classical relational calculus uses set semantics, meaning duplicate result tuples are not retained, and true-or-false logic. The examples use non-NULL attribute values to avoid differences caused by SQL’s treatment of missing values.

Tuple Relational Calculus (TRC)

In Tuple Relational Calculus, a variable represents a complete tuple. Individual values are accessed through attribute names, such as s.Name or s.Semester. The dot separates the tuple variable from the attribute being accessed.

The general form is:

Read this as: “The set of tuples t such that condition P(t) is true.” The braces { } indicate a result set, the vertical bar | means “such that,” and P(t) represents the condition that tuple t must satisfy.

For a Student tuple s, Student(s) establishes membership in the Student relation, while s.Semester = 2 checks whether its semester equals 2. Membership can also be written as s ∈ Student, where ∈ means “belongs to.”

The result tuple does not have to contain every input attribute. Its output schema can contain selected attributes, with conditions connecting those output values to the relevant input tuples.

Domain Relational Calculus (DRC)

In Domain Relational Calculus, each variable represents one value rather than a complete row.

Its general form is:

Read this as: “The set of value combinations that satisfy condition P.” The angle brackets ⟨ ⟩ group the output values into a tuple, and | means “such that.” Each variable represents one value in that tuple.

For the Student schema, the relation predicate is:

Here, i represents a student ID, n a name, did a department ID, and sem a semester. Their positions follow the declared schema order.

This predicate requires the four values to occur together in an existing Student tuple. It does not allow an ID from one row to be combined arbitrarily with a name from another row.

A shared variable can also connect relations. Using the same department-ID variable in Student and Department requires their department values to match.

Predicates and Formulas

A predicate is a condition that evaluates to true or false for particular values. More complex conditions are built from smaller units called atomic formulas.

Typical atomic formulas include:

• Relation membership: Checking whether a tuple or combination of values belongs to a relation.

• Comparison with a constant: Checking whether a semester equals 2.

• Comparison between attributes: Checking whether a student’s department ID equals a department’s ID.

Comparison symbols have their usual meanings: = means equal, ≠ means not equal, < and > mean less than and greater than, while ≤ and ≥ include equality.

Logical operators combine these atoms. AND (∧) requires both conditions to be true, OR (∨) requires at least one to be true, and NOT (¬) negates a condition.

Quantifiers extend formulas by expressing requirements about other tuples or values. Parentheses identify which conditions belong together and which part of the formula a quantifier controls.

Free and Bound Variables

A variable occurrence is bound when it is controlled by a quantifier such as ∃ (“there exists”) or ∀ (“for every”). An occurrence outside such a quantifier’s scope is free.

Free variables determine the answer being described. Bound variables help establish that the answer satisfies the required conditions.

In the standard TRC form { t | P(t) }, meaning “tuples t such that P(t) is true,” t is the free result variable. Other tuple variables used to search for supporting rows are quantified. In DRC, the variables listed in the output tuple are free, while additional variables are quantified.

A relation predicate can restrict a variable’s possible values without making it logically bound. For example, membership in Student restricts which tuples qualify; a quantifier is what binds the variable within its scope.

Existential and Universal Quantifiers

The existential quantifier, ∃, expresses an “at least one” requirement. A department has students if at least one Student tuple carries that department’s ID.

The universal quantifier, ∀, expresses an “every” requirement. Saying that every student in a department is in Semester 2 means that no student in that department violates the semester condition.

For a restricted universal condition, implication (⇒) separates the relevant candidates from the requirement they must satisfy: if a tuple belongs to the relevant group, then it must satisfy the condition. This symbol describes a logical requirement, not an execution step.

A useful logical equivalence is:

Here, ∀ means “for every,” ∃ means “there exists,” ¬ means NOT, and ≡ means “is logically equivalent to.”

The expression therefore says: “Every x satisfies P” is equivalent to “there is no x that fails P.” It explains why SQL often uses NOT EXISTS to express universal requirements.

Safe Expressions and Domain Independence

An unrestricted calculus expression can describe an infinite result. For example, asking for every possible integer that is not stored as a student ID could include infinitely many values outside the database.

A safe expression avoids this problem by keeping its answers grounded in database values and relevant query constants. Relation-membership conditions are a common way to restrict the candidates under consideration.

The active domain is the set of values actually appearing in the database. Safe query formulations allow evaluation using relevant finite values instead of requiring a search through an unrestricted universe.

A related concept is domain independence: adding unrelated values to the underlying domain, without changing the database, should not change the query’s answer. Merely obtaining a finite result on one database instance is not enough to establish this property.

Negation requires particular care. “Existing students who do not meet a condition” has a defined candidate set. “Every possible tuple that is not a student” does not have the same restriction.

A Compact Example

Requirement: Return the names and department names of students in Semester 2.

The following TRC and DRC expressions describe the same result. They are mathematical notation, not executable SQL.

Tuple Relational Calculus :

Let the output tuple t have the schema (Name, DeptName).

Read ∃s ∃d as “there exist tuples s and d.” Each ∧ means AND, so all the listed conditions must hold. The vertical bar | means “such that,” separating the result tuple from its conditions.

Here, t is free, while s and d are bound by existential quantifiers. The expression requires a matching student and department, checks the semester, and connects the output attributes to their values.

Domain Relational Calculus :

The output tuple ⟨n, dn⟩ contains a student name and department name. Each ∃ means that a supporting value must exist, while ∧ means that all the conditions must hold.

Here, n and dn are the free output variables. The variables i, did, and sem are bound. Reusing did in both relation predicates expresses the department match.

Result :

DISTINCT matches the set semantics of relational calculus: if multiple qualifying students produced the same output values, the result would contain that output tuple once. The displayed row order is illustrative; a particular SQL ordering requires ORDER BY.

Expressing “For Every” with NOT EXISTS

Requirement: Return departments in which every assigned student is in Semester 2.

The universal condition can be written in TRC as follows:

Here, ∀s means “for every tuple s,” ∧ means AND, and ⇒ means “if … then.” The membership and department conditions identify the relevant students.

Read the implication as: “If s is a student assigned to this department, then s must be in Semester 2.” Its SQL translation looks for departments with no violating student.

<> means “not equal” in SQL. Inside EXISTS, SELECT 1 checks whether a qualifying row exists; it does not count the rows.

Result :

Computer Science qualifies because both its students are in Semester 2. Electronics fails because Ravi is in Semester 4.

Mathematics also qualifies because it has no student who violates the condition. This is vacuous truth: a universal statement over an empty relevant set is true. If the requirement also demands at least one student, a separate existence condition is needed.

These translations use the stated non-NULL assumption. SQL comparisons involving NULL can produce unknown, so classical true-or-false reasoning must be adjusted when missing values are allowed.

Summary

Tuple Relational Calculus and Domain Relational Calculus describe the conditions that database results must satisfy. TRC uses tuple variables, while DRC uses individual value variables. Predicates, logical connectives, quantifiers, and variable scope provide the structure for expressing these conditions precisely.

Safe expressions keep queries grounded in relevant finite data, and safe TRC and DRC have the same expressive power as classical relational algebra. Their connection to SQL is visible in filtering, joins, EXISTS, and NOT EXISTS, with additional attention needed for duplicates, missing values, and universal conditions over empty sets.