Consider a database that has the relation schemas EMP(EmpId, EmpName, DeptId),…

2017

Consider a database that has the relation schemas EMP(EmpId, EmpName, DeptId), and DEPT(DeptName, DeptId). Note that the DeptId can be permitted to be NULL in the relation EMP. Consider the following queries on the database expressed in tuple relational calculus.

I.    {\(t\) | ∃u ∈ EMP(t[EmpName] = u[EmpName] ∧ ∀v ∈ DEPT(t[DeptId] ≠ v[DeptId]))}

II.    {\(t\) | ∃u ∈ EMP(t[EmpName] = u[EmpName] ∧ ∃v ∈ DEPT(t[DeptId] ≠ v[DeptId]))}

III.    {\(t\) | ∃u ∈ EMP(t[EmpName] = u[EmpName] ∧ ∃v ∈ DEPT(t[DeptId] = v[DeptId]))}

Which of the above queries are safe?

Answer: D. I, II and IIIConcept — when is a tuple relational calculus query safe? A query {t | φ(t)} is safe when it is guaranteed to return only finitely many tuples on every…

  1. A.

    I and II only

  2. B.

    I and III only

  3. C.

    II and III only

  4. D.

    I, II and III

Attempted by 127 students.

Show answer & explanation

Correct answer: D

Concept — when is a tuple relational calculus query safe? A query {t | φ(t)} is safe when it is guaranteed to return only finitely many tuples on every database instance. The strict (domain-independence) test for this is range-restriction: every attribute of the output tuple t must be equated — directly or transitively — to a value drawn from a named, finite relation (∈ EMP or ∈ DEPT). If an attribute is only compared with ≠ to relation values, or left otherwise free, it can still take any value from the underlying domain, and the query is unsafe by that strict test.

Applying it to each query — all three introduce t through the identical clause ∃u ∈ EMP(t[EmpName] = u[EmpName] ∧ …), so t[EmpName] is always one of the finitely many names in EMP. That clause ties only t[EmpName]; it does not equate t[DeptId] to u[DeptId]. So what matters is how each query constrains t[DeptId]:

  • Query I — ∀v ∈ DEPT(t[DeptId] ≠ v[DeptId]): t[DeptId] is only ever compared with ≠ to v[DeptId] for v ∈ DEPT; it is never equated to a DEPT value. Strictly, t[DeptId] may then be any value outside DEPT's finite set of ids — an unbounded space — so by the strict test this alone does not guarantee finiteness.

  • Query II — ∃v ∈ DEPT(t[DeptId] ≠ v[DeptId]): weaker still — it needs only some DEPT id to differ from t[DeptId]. For any DEPT with more than one distinct id this holds for almost every value of t[DeptId], so strictly t[DeptId] is again unbounded.

  • Query III — ∃v ∈ DEPT(t[DeptId] = v[DeptId]): t[DeptId] is equated to an actual DeptId drawn from DEPT, pinning it to DEPT's finite set of ids — the one query that is airtight under the strict test.

Two conventions and the official answer — by the strict domain-independence definition above, only Query III is airtight; but "III only" is not among the offered options. Many exam solutions instead apply a looser, purely syntactic range-restriction convention: any comparison of a free tuple's attribute against a variable bound to a named relation (here v ∈ DEPT) is treated as range-restricting, whatever the operator (=, ≠) or quantifier (∃, ∀). Under that convention all three queries come out safe, and that is the answer recorded on the official GATE 2017 key for this item. This is why the item resolves to all three even though the strict reading would isolate only Query III. Answer (per the exam's convention): I, II and III are safe.

A video solution is available for this question — log in and enroll to watch it.

Explore the full course: Iocl Engineers Officers Grade A Paper 2

Loading lesson…