Relational Calculus

Tuple Relational Calculus (TRC) in DBMS

Tuple Relational Calculus is a non-procedural query language. It specifies what to retrieve, not how to retrieve it. A TRC query defines a set of tuples that satisfy a predicate rather than describing an explicit sequence of operations.

The general form of a TRC query is:

{ t | P(t) }

where:

• t is a tuple variable that ranges over tuples of relations, and the result of the query is the set of such tuples t for which the predicate holds.
• P(t) is a predicate - a condition built from relation membership, attribute comparisons, logical connectives, and quantifiers.

Typical atomic predicates are of the forms t ∈ R (t is a tuple of relation R) and t[A] Θ value or t[A] Θ s[B] where Θ is a comparison operator (=, ≠, <, ≤, >, ≥).

Logical connectives used in predicates include AND (∧), OR (∨), and NOT (¬). TRC also uses quantifiers over tuple variables:

• ∃ u ∈ R (Q(u)) - there exists a tuple u in relation R such that Q(u) is true.
• ∀ u ∈ R (Q(u)) - for all tuples u in relation R, Q(u) is true.

Free tuple variables in the outermost expression determine the schema of the resulting relation. An expression with no free tuple variables returns a relation with zero attributes (a truth value as an empty tuple), but in practice we use free tuple variables to select attributes for the result.

Examples and worked queries (TRC)

Schema and sample relations:

Table-1: Customer

Table-2: Branch

Table-3: Account

Table-4: Loan

Table-5: Borrower

Table-6: Depositor

Queries-1: Find the loan number, branch and amount of loans whose amount is greater than or equal to 10000.

{ t | t ∈ loan ∧ t[amount] >= 10000 }

Resulting relation:

In this query the tuple variable t ranges over tuples of relation loan; t[amount] denotes the amount attribute of t.

Queries-2: Find the loan number for each loan whose amount is greater than or equal to 10000.

{ t | ∃ s ∈ loan (t[loan-number] = s[loan-number] ∧ s[amount] >= 10000) }

Resulting relation:

Queries-3: Find the names of all customers who have both a loan and an account at the bank.

{ t | ∃ s ∈ borrower (t[customer-name] = s[customer-name]) ∧ ∃ u ∈ depositor (t[customer-name] = u[customer-name]) }

Resulting relation:

Queries-4: Find the names of all customers who have a loan at the "ABC" branch.

{ t | ∃ s ∈ borrower (t[customer-name] = s[customer-name] ∧ ∃ u ∈ loan (u[branch-name] = "ABC" ∧ u[loan-number] = s[loan-number])) }

Resulting relation:

Notes on TRC (practical and theoretical)

• Free and bound variables: Variables that appear outside the scope of quantifiers are free and determine the output columns. Variables inside quantifiers are bound and used only within the predicate.
• Safety (range-restrictedness): A TRC expression must be safe (range-restricted) so that the result is finite and depends only on the input relations. Informally, every free variable must be constrained by a relation membership or by comparisons to values that limit it to a finite set.
• Expressive power: Safe TRC is equivalent in expressive power to relational algebra (and thus to non-recursive SQL without aggregation or recursion).
• Limitations: TRC does not provide built-in aggregation (SUM, COUNT) or recursion; these require extensions.

Domain Relational Calculus (DRC)

Domain Relational Calculus is another non-procedural query language. Instead of tuple variables, DRC uses domain variables that range over atomic domain values (attribute values). A DRC query returns tuples of domain values that satisfy a predicate.

The general form of a DRC query is:

{ < x1, x2, ..., xn > | P(x1, x2, ..., xn) }

where each xi is a domain variable and P is a predicate built from:

• comparisons between domain variables and constants or between domain variables,
• connectives: AND (∧), OR (∨), NOT (¬),
• quantifiers over domain variables: ∃ and ∀,
• membership predicates which link domain variables to relation tuples in the form <v1, v2, ... , vk> ∈ R.

Examples and worked queries (DRC)

Schema and sample relations:

Table-1: Customer

Table-2: Loan

Table-3: Borrower

Query-1: Find the loan number, branch and amount of loans with amount greater than or equal to 100.

{ <l, b, a> | <l, b, a> ∈ loan ∧ (a ≥ 100) }

Resulting relation:

Query-2: Find the loan number for each loan whose amount is greater than or equal to 150.

{ <l> | ∃ b, a ( <l, b, a> ∈ loan ∧ a ≥ 150 ) }

Resulting relation:

Query-3: Find the names of all customers having a loan at the "Main" branch and report the loan amount.

{ <c, a> | ∃ l ( <c, l> ∈ borrower ∧ ∃ b ( <l, b, a> ∈ loan ∧ b = "Main" ) ) }

Resulting relation:

Note: Domain variables that appear in the result must be listed before the bar (|) inside < and >. The order of variables in the resulting tuple should correspond to the attribute order used in predicates or to the target schema expected by the query.

Relationship between TRC and DRC

• Variable type: TRC uses tuple variables (each variable represents an entire tuple). DRC uses domain variables (each variable represents a single attribute value).
• Equivalence: Under the restriction of safety (range-restricted expressions), TRC and DRC are equivalent in expressive power; both are equivalent to relational algebra for non-recursive queries.
• Usage preference: TRC is often more convenient when manipulating whole tuples and when relation membership checks are natural. DRC can be more concise when expressing conditions on individual attribute values.

Safety and domain independence

For a calculus expression to be usable in practice it must be safe (also called range-restricted). Safety guarantees the result is finite and depends only on the active domain (the set of values actually present in the database), not on some infinite underlying domain.

Typical conditions ensuring safety:

• Every free variable must appear in some positive atomic formula that constrains it to a finite set of values (for example, membership in a relation or equality to a constant or to another variable that is so constrained).
• Queries that use only negation without constraining variables may be unsafe because they could range over an infinite domain.

Safe and domain-independent expressions correspond to relational algebra queries and can be translated to SQL (without aggregation or recursion).

Translating calculus queries to relational algebra / SQL (brief)

Translations follow these general ideas:

• Each atomic predicate of the form t ∈ R or <v1,...,vn> ∈ R corresponds to using the relation R in the algebra expression.
• Equalities between attributes correspond to join conditions.
• Existential quantifiers (∃) correspond to projection after selection and join; universal quantifiers (∀) are expressed using negation and exists (set difference / NOT EXISTS in SQL) or via division where appropriate.
• Logical connectives map to selection (AND), union (OR), and set difference/complement (NOT) in relational algebra; in SQL they map to WHERE conjunctions, UNION, and NOT EXISTS / NOT IN constructs.

Example idea (informal translation):

For the TRC query { t | t ∈ loan ∧ t[amount] >= 10000 } the translation to relational algebra is:

Select tuples from loan where amount >= 10000. In SQL:

SELECT loan-number, branch-name, amount FROM loan WHERE amount >= 10000;

Practical remarks for exam and application

• Understand both tuple and domain styles; many problems ask to express the same query in TRC, DRC and relational algebra or SQL.
• Always check safety: ensure free variables are range-restricted by membership or explicit bounds.
• Be able to convert simple existential TRC expressions to selection-projection-join sequences in relational algebra or to SELECT-FROM-WHERE SQL queries.
• Know typical patterns: existential quantification for joins, universal quantification via negation or division, and correlation for nested queries.

Summary

Tuple and Domain Relational Calculus are declarative formalisms that describe the set of desired tuples or attribute values using predicates and quantifiers. When expressions are safe, both calculi are equivalent to relational algebra and can be implemented using SQL. Key practical skills are expressing queries correctly in both calculi, checking range-restriction (safety), and translating calculus expressions to algebra/SQL for execution.