Relational Model & Theory

A domain is the set of values an attribute may take, plus the operations defined on them. A narrow domain rejects impossible values at write time, gives correct comparison and ordering semantics, and lets the engine store and compare values efficiently instead of every reader re-parsing text.

The database schema is every relation schema - names, attributes, domains - plus all constraints, including ones spanning relations such as referential constraints. The database instance is one instance of each relation, all satisfying those constraints together. In SQL, 'schema' also means a namespace grouping objects, which is a different idea.

An outer join keeps dangling tuples — those with no matching partner — and pads their missing attributes with null. Basic relational algebra has no null value and no operator that invents one, so outer join needs both an extension to the value domain and an operator definition of its own.

It changes the answer whenever an outer row matches more than one inner row: the semi-join returns that row once, the inner join returns it once per match. Equivalence requires either a proof that the join key is unique on the inner side, or an explicit duplicate elimination on the outer row's identity after the join.

Safe only if every attribute the selection predicate references survives the projection. Otherwise the filter has no column to test. When safe, projecting first narrows tuples early, cutting memory and I/O through the rest of the plan.

Set difference deduplicates, so count mismatches vanish; it compares whole rows positionally, so a column-order or type-coercion difference makes everything look different; and it says which rows differ, not which columns. Compare on a key with a value-level check instead.

Because for many views a change to the view has no unique translation back to base rows — joins, aggregates and set operations are ambiguous or lossy. Engines auto-update only simple single-table views and require an explicit handler, such as an INSTEAD OF trigger, for the rest.

Create the new tables, then expose a view with the old table's name and shape so read paths keep working while consumers migrate. It runs out on writes (only simple views are updatable), on non-derivable changes such as cardinality shifts, on performance, and on the double-write period during backfill.

No. A foreign key must reference a candidate key of the parent, meaning a declared unique, minimal attribute set. The primary key is the usual target because it is stable and non-null, but any enforced candidate key works. Referencing non-unique attributes is meaningless because the reference would not denote one row.

A safe expression is one whose result contains only values already present in the database or in the query, so it is finite and independent of the underlying domains. Unsafe expressions, typically unrestricted negation such as 'all tuples not in R', describe infinite or domain-dependent results that no engine can compute.

Both the heading and the body are sets, and sets have no order, so position is not part of the value. Engines exploit that freedom: storage reorganisation, updates relocating rows, parallel scans and plan changes all reorder results, so code assuming stored order breaks intermittently with no code change to blame.

A constraint is a predicate declared on the schema, so it must hold for every instance the database is ever allowed to reach, not just the current one. A property that merely happens to be true of today's data guarantees nothing. Enforcement therefore checks state transitions, and some constraints must be checked at transaction end rather than per statement.

Take all candidates (project the dividend onto the non-divisor attributes), pair every candidate with every divisor value via Cartesian product, subtract the pairs that actually exist in the dividend — what remains are the missing pairs. Project those onto the candidate attributes to get the disqualified candidates, and subtract them from all candidates.

He separated 'missing but applicable' (a value exists, unknown to us) from 'missing and inapplicable' (no value can exist), proposing two markers and four-valued logic. One marker conflates them, so queries cannot tell them apart. Today the usual answer is decomposition into separate tables or an explicit status column.

In bag algebra each tuple carries a multiplicity. Projection no longer removes duplicates, union adds multiplicities instead of merging, and idempotence, absorption and some distributive laws fail. An optimizer may therefore only insert or remove duplicate elimination where the enclosing context is insensitive to multiplicity.

Non-subversion means bulk loaders and record-level APIs must not skip constraints or authorisation. Mainstream engines commonly fall short on view updating, integrity independence, distribution independence and full non-subversion. It matters as a checklist of where your team must compensate, not as a product-selection score.

Break it when a physical fact drives a decision the logical layer cannot express and the cost is measured, not assumed — partition keys, clustering-aware access patterns, denormalisation for read cost, sharding keys. Contain it by writing the dependency down, testing it, and giving it an owner and a review trigger.

Relationally complete means the language can express every query expressible in relational algebra, equivalently in safe relational calculus, which is Codd's theorem. It is a floor, not a ceiling: first-order power excludes counting and aggregation, and transitive closure such as reachability, so real languages add extensions.

Prefer the schema: a unique constraint makes the table a set on every write, is race-proof, and lets the planner skip duplicate removal. Write-path logic alone races; read-time deduplication taxes every query and hides the defect. Read-time dedup is right only when duplicates are legitimate events.