What is a 'safe' expression in relational calculus, and what goes wrong with an unsafe one?

## Where the problem comes from Relational calculus is first-order logic dressed for databases, and logic happily lets you write formulas whose satisfying set is infinite. Nothing in the grammar objects to: `{ t | NOT Employee(t) }` Read literally: every tuple, of the right shape, that is not an employee. If the attribute domains include the integers or arbitrary strings, that set is infinite. No engine can enumerate it, and no algebra expression can produce it, because every algebra operator returns values drawn from its inputs. The subtler failure is **domain dependence**. Even if every domain were made finite, the answer would depend on the *declared* domains rather than on the stored data: widening a column's type from a two-character code to a four-character code would silently change the result of a query nobody edited. A query language whose answers move when the type definitions move is not usable. ## Active domain and the definition of safety The repair is the **active domain**: the finite set of values that actually occur somewhere in the current database instance, together with the constants written in the query itself. An expression is **domain independent** if its result is the same no matter which superset of the active domain the variables are taken to range over. Domain independence is the property you actually want, but it is undecidable in general, so the formalism uses **safety**: a set of syntactic conditions that are decidable, guarantee domain independence, and are expressive enough to lose nothing important. The conditions, in their usual informal form: 1. **Bounded results.** Every free variable that contributes to the output must be constrained by a positive relation atom, so all output values come from stored data or query constants. 2. **Relativised negation.** `NOT P(x)` may not stand alone; it must be conjoined with a positive atom that already restricts x, as in `Employee(x) AND NOT Manager(x)`. This turns an unbounded complement into a bounded difference. 3. **Bounded quantification.** A quantified variable must be ranged over a relation, that is `EXISTS x ( R(x) AND ... )` rather than `EXISTS x ( ... )` over an unspecified universe. The same applies to universal quantifiers, usually with an implication whose antecedent supplies the bound. Under these conditions the result is finite and depends only on the data. ## Why safety is load-bearing rather than pedantic Codd's theorem, the statement that calculus and algebra have equal expressive power, is stated for **safe** calculus. The direction from calculus to algebra could not hold otherwise, since algebra is closed over the values in its inputs and can never invent a value that appears nowhere. Safety is the exact condition that makes the two formalisms line up, so it is a hypothesis of the central theorem of the relational model, not a footnote. ## How practical languages inherit it Every real query language enforces safety by construction rather than by checking. You never write "everything that is not in this relation"; you write a difference against a named source, or a non-existence condition attached to a row you are already scanning. Quantified conditions are always attached to a subquery over a named relation, so the variable is bounded automatically. The result is that unsafe queries are simply not expressible, which is why most practitioners meet the concept only when studying the formalism. The intuition still pays off in day-to-day design. "Find the customers with no orders" is safe, because the answer is bounded by the customer relation. "Find the orders that could have been placed but were not" is unsafe until you name the space of possibilities as a relation, for example a calendar or a product catalogue, at which point it becomes a difference against a real source. Recognising that a requirement needs a generated universe relation before it can be answered is exactly the safety condition showing up in practice. ## Common misunderstandings Safety is not about performance. A safe expression can still be enormously expensive; safety only guarantees the result is finite and data-determined. Nor is safety about nulls or three-valued logic, which is a separate matter of how unknown values interact with predicates. And a query with negation is not automatically unsafe: negation is fine as soon as it is relativised to a bounded variable, which is the overwhelmingly common case.