Schemas and Satisfaction

Of things said without any combination, each signifies either substance or quantity or qualification or a relative or where or when or being-in-a-position or having or doing or being-affected.

A schema is a signature: a set of types, predicates, arities, and constraints that determines which structures count as models. Adding a predicate therefore changes the language in which claims can be expressed and tested. A3 and A3b make that change explicit.

The Query That Cannot Be Typed

The database is perfect. Every dress has a primary key. Every attribute is typed. Foreign keys enforce referential integrity. Constraints prevent impossible states: price must be positive, size must be in the allowed set, color must come from the approved palette. The schema is a contract, and the data honors it.

A user asks: "Show me something less puffy."

The catalog can store the word "puffy" before it has an agreed meaning for the user. It can also evaluate a supplied expression, create a typed function or view, or represent predicate definitions in a registry. The unresolved task is to give puffiness an interpretation, evidence, and a contract that downstream consumers can rely on.

A new symbol extends the logical vocabulary used by those consumers. That need not entail a new physical column or a scheduled data migration: the storage schema may already represent extensible definitions. Conversely, adding a column does not establish that its values express the intended concept.

A3 treats the operative vocabulary as a signature. The distinction needed here is between storing a name, defining its interpretation, and governing its use.

What the Relational Empire Bought

Codd's proposal separated a user's logical description of data from details of its physical storage¹. A query should not have to follow the access path laid down for an earlier application. That independence gives a database administrator room to change the representation while preserving the question the user asks. The selected Volume I account develops this achievement historically; here it supplies the reason to care about preservation contracts.

Relational implementations can enforce keys, foreign-key references and declared constraints over the records they govern. An enforced reference to a customer record establishes that the record exists. Whether it identifies the intended customer is another inquiry. Deletion and update behavior likewise depend on the declared constraints and actions; the relational model does not prescribe a universal ban on deleting a referenced record.

Transaction mechanisms add guarantees about coordinated changes and recovery². Query optimizers can choose among execution plans without requiring the query author to specify one. These later facilities serve the independence Codd sought, but they are separate implementation achievements. Their protection depends on the checks, isolation and recovery behavior actually supplied.

The saving is considerable. An application can rely on an enforced invariant instead of rediscovering it in every operation. When the invariant changes, that reliance gives the change a consequence beyond the table being altered.

A declared schema constrains the data and operations it covers. Its vocabulary can evolve, and definitions derived from existing data can be exposed through views or typed functions. Some changes require migrations and downstream coordination; others fit within an existing extension mechanism. The governance problem is deciding and preserving the intended contract, not an inability of relational systems to execute vocabulary changes.

The Escape Hatches

Several familiar designs represent vocabulary more flexibly. Their guarantees depend on the constraints retained in the particular design.

Entity-Attribute-Value (EAV). A registry can associate attribute identifiers with domains and typed value relations. Foreign keys and declared checks can preserve selected invariants. A design that instead puts arbitrary values under arbitrary names leaves those guarantees unspecified. Neither choice determines whether two attributes mean the same thing.

JSON columns. JSON permits flexible structure, while database expressions and checks can constrain selected fields. PostgreSQL also supports JSONB indexing. The relevant question is which structure and invariants the deployment validates, not whether JSON necessarily forfeits validation or useful query plans.

Tag tables. Tags can be free text or references to governed concepts. A typed registry can attach scope, provenance, and declared relationships. Those records support a semantic contract; their existence alone does not justify it.

Flexibility shifts where the contract is represented and checked. It does not logically require abandoning the contract. The proposed admission discipline must therefore explain what evidence and enforcement it adds to these designs, while accepting the same responsibility to implement its own checks.

Schema as Signature

What each extension preserves can be examined more precisely through the schema’s formal representation.

A schema is not a "table definition" in the colloquial sense. It is a signature: a formal declaration of the language in which data can be expressed. The signature specifies what distinctions can be made, what questions can be asked, what constraints must hold.

This is why schema changes are governance events. You are not changing data; you are changing the language in which data can be expressed. Old queries remain well-formed in the extended language, but their contract can break—through interface assumptions, constraint changes, or altered NULL/typing semantics. New queries may be meaningless for old data. Applications that assumed one vocabulary must be updated to speak another.

A schema is language about data. A migration is language about language. The confusion that "adding a column" is a trivial data operation arises from conflating these levels. When you change the schema, you change the space of expressible distinctions—and sometimes the very well-formedness or meaning of downstream questions—not just which statements happen to be true.

A consumer can ask which of its existing questions remain meaningful and which guarantees the new representation actually preserves.

Model and Satisfaction

The schema declares predicates and constraints. A model interprets them, allowing us to ask whether the constraints hold and what a proposed change preserves.

Conservativity supplies one formal test for safe evolution. If a column can be added while every declared stable query retains its result on every dataset in scope, the change is operationally conservative for that query contract. If answers change or old queries become ill-formed, that contract has been broken even when no new theorem in the old language follows.

items(id INT PRIMARY KEY, price DECIMAL CHECK (price > 0))

items(id INT PRIMARY KEY, price DECIMAL CHECK (price > 0), 
      puffiness VARCHAR(20) CHECK (puffiness IN ('none','subtle','dramatic')))

The third case is the trap. Conservativity is a logical property, but breaking changes often appear at the application or semantic layer. SQL NULL does not mean false. It can leave different reasons for absence unrepresented, while an application may choose to treat absence as a negative answer. The new column can leave the first query intact while introducing just such an unsupported inference elsewhere.

The next chapter asks what the source’s absence convention permits a recipient to infer. A closure policy and a consequence relation both need to be explicit; they perform different work.

Four Failures of Vocabulary Rigidity

The next touchstones identify contracts that a changing vocabulary needs. They are failure cases for the illustrated designs, not limitations of every relational implementation.

T6: Predicate Invention

"Show me puffy dresses."

The catalog schema has predicates for color, size, price, silhouette, fabric, brand. It does not have a predicate for puffiness. The request introduces a distinction the displayed attributes do not yet define. A useful interpretation might be derived from them, or it might require additional evidence.

To add puffiness as a certified predicate, the system must traverse governance layers:

When a new term changes a shared contract, semantic definition, evidence collection, and downstream coordination can dominate the work. A local or derived predicate may need much less. The burden depends on its intended authority and use; a scheduled migration is one workflow, not a necessary feature of relational predicate admission.

T7: Contextual Equivalence

"NYC" and "New York City" refer to the same place—sometimes.

Two records in the catalog list supplier locations. Supplier A is based in "NYC." Supplier B is based in "New York City." Are these the same location? A supplier may use one label for a delivery region and another for a municipal address. In this hypothetical, the receiver must establish what each field denotes before substituting one for the other.

The relational empire can enforce equivalence. The standard pattern is a canonical-ID table with an alias lookup:

locations(canonical_id INT PRIMARY KEY, canonical_name VARCHAR)
location_aliases(alias VARCHAR PRIMARY KEY, canonical_id INT REFERENCES locations)

The limitation is not representational impossibility. It is scope and governance.

Declaring equivalence is itself a governed act. Who decides that "NYC" = "New York City"? What process blesses that mapping? What happens when someone disagrees?

A mapping keyed only by alias applies without a context parameter. A context-indexed mapping can instead record scope, evidence, authority, and validity periods. Either design is representable relationally. The relevant question is whether consumers select the intended scope and enforce the conditions that justify the substitution.

This is ongoing governance of meaning, not a representational impossibility. A witnessed equivalence package proposes an explicit contract for the work; its checks still require implementation.

T9: Schema Evolution

Employees and contractors were once separate concepts. The company had two tables: employees with salary, benefits, and tenure; contractors with hourly rate, agency, and contract end date. Reports were written against these tables. Dashboards displayed headcounts by type. Payroll systems knew which table to query.

Suppose the company now wants a combined worker report. It can define a “workers” view covering both tables while preserving the attributes and obligations that distinguish employees from contractors.

This is schema evolution under concept drift. The organization wants another way to address its records; the change must preserve the distinctions its continuing decisions require.

Replacing the source relations with a common worker table would require more:

• Data transformation. The new representation must retain the relevant attributes and distinguish duplicate entries from a person holding both roles.
• Constraint rewriting. Constraints attached to a removed relation need an equivalent expression in the replacement.
• Application updates. Consumers of removed tables need revision or a preserved interface.
• Downstream coordination. Payroll, benefits, reporting systems all have their own assumptions.

If the migration removes the old tables without compatible views, a query such as SELECT COUNT(*) FROM employees loses its target. Adding a workers view alongside the old relations can preserve it. Combining records also leaves the organization responsible for distinctions its decisions still require.

Breaking changes require version compatibility certificates—explicit documentation of what changed, what broke, and how to migrate—or a migration plan that preserves backward compatibility through views, synonyms, or API versioning.

T10: Higher-Arity Events

"Alice introduced Bob to Carol at the conference."

This is a single event with four participants: an introducer (Alice), two introducees (Bob and Carol), and a context (the conference). The event has structure: Alice is the agent; Bob and Carol are the patients; the conference is the setting. There are constraints: the introducer cannot be one of the introducees.

The relational model can represent this cleanly. An introductions table with four foreign keys—introducer_id, introducee_1_id, introducee_2_id, context_id—plus role constraints and timestamps. Perfectly valid SQL.

The problem is not representational impossibility. It is representational default.

Consider instead a representation that stores the two introductions as separate binary edges and records the conference against an event identifier without linking that identifier to the participants:

• (Alice, introduced, Bob)
• (Alice, introduced, Carol)
• (introduction_event_42, at, conference)

The decomposition loses structure. The per-edge constraint “introducer ≠ introducee” remains expressible: each introduced edge contains both endpoints. What this decomposition omits is the grouping of the two introducees into one particular event. Recovering which introducees belonged to which introduction needs an event key or equivalent grouping structure. Chapter 29 exhibits two event collections with identical ungrouped role edges and different answers to that query. The role structure—who introduced whom to whom—is implicit rather than typed.

The failure mode is not "relational can't do n-ary." It is "the default path loses n-ary structure, and the loss appears as constraints you can no longer enforce."

The Fashion Catalog Revisited

Return to the running example with the full machinery in view.

The catalog schema:

items(id INT PRIMARY KEY,
      category VARCHAR(50),
      subcategory VARCHAR(50),
      price DECIMAL(10,2) CHECK (price > 0),
      color VARCHAR(30),
      silhouette VARCHAR(30) CHECK (silhouette IN ('fitted','relaxed','A-line','empire','shift')),
      fabric VARCHAR(50),
      brand VARCHAR(100))

Suppose this hypothetical catalog initially represents category, price, color, silhouette, fabric and brand. Later queries ask it to distinguish:

• Puffiness — a style dimension that cuts across silhouette
• Flowy — a movement quality that depends on fabric and cut and weight
• Cottagecore — an aesthetic whose maintained definition may combine several represented attributes
• Coastal grandmother — a style label absent from the displayed fields
• Quiet luxury — a positioning that depends on brand perception, not intrinsic attributes

The schema is correct for what it declares, but incomplete for what users need.

Some newly useful terms can be defined from existing attributes; others need new measurements, labels, or judgments. Their intended use determines the required evidence, compatibility checks, and coordination.

The catalog can represent such terms through columns, views, typed functions, tags, or structured metadata. Each design can retain selected guarantees when the relevant checks are declared and enforced. A free-text match alone supplies no assertion-polarity contract; a typed record alone supplies no evidence that the chosen definition matches the user's meaning.

The receiving operation needs to know which definition governs the new term, what supports its application and which earlier queries still have their promised meaning. Those obligations apply whichever storage design supplies the predicate.

A schema can enforce represented constraints while a requested predicate still lacks a maintained definition. Even within its vocabulary, an application may interpret an empty cell as unknown, inapplicable, omitted, or negative⁶. The next obligation is therefore logical as well as lexical: a view must disclose what absence permits it to infer.