Data Is Not the Table That Contains It

Abstract

Relational tables are among the most successful abstractions in computing, but their success has encouraged a conceptual shortcut: treating the table as if it were the data’s natural form. This essay argues that a table is a storage and query representation, not the ontology of the phenomenon represented. It distinguishes logical relations from physical tables, records from events, attributes from meanings, and denormalised convenience from conceptual integrity. Relational algebra, functional dependencies, temporal modelling, and graph relations are used to show why the same domain object can be represented in multiple physical forms and why one table may contain several conceptual entities. The cultural argument is that tabular thinking privileges what can be rendered as rows and columns, sometimes hiding process, sequence, uncertainty, and context. A computational Data Platform should use tables rigorously without allowing them to dictate the boundaries of meaning.

1. The table’s extraordinary success

The relational model achieved a decisive separation between logical data structure and physical storage. Relations could be manipulated through declarative operations rather than navigational access paths. Yet everyday engineering often collapses this distinction again. The physical table becomes the conceptual unit: one source table is copied into one bronze table, transformed into one silver table, and exposed as one business entity.

Codd’s relational model concerns relations over domains, not spreadsheet-like containers. A relation $R$ is a set of tuples satisfying a heading and constraints. A physical table is one implementation. Even at the database level, ordering, duplicates, nulls, indexes, and storage details complicate the pure model.

At the domain level, the distance is larger. A row may not correspond to one event or entity. It may be a snapshot, a denormalised join, a document fragment, or an operational convenience.

2. Rows are not necessarily events

Suppose a row contains patient attributes, encounter attributes, order details, result values, and report status. It may be tempting to call the row a “report record.” But several identities and temporalities coexist.

Let row $r$ have attribute set $A$. Conceptual decomposition seeks subsets

corresponding to person, encounter, order, result, and report. The subsets may overlap through keys and provenance. The source row is a materialised conjunction of claims, not necessarily one object.

If updates affect only some components, treating the row as atomic can generate duplication and temporal inconsistency. The platform should decompose according to identities and invariants, then recompose views for consumption.

3. Functional dependencies reveal hidden objects

Functional dependencies help identify conceptual structure. If

while

and

then storing all attributes in one table creates repeated patient and order facts. Normalisation theory addresses update anomalies, but the platform concern goes beyond normal forms. It concerns ownership, lifecycle, and semantic reuse.

A patient attribute may be corrected independently of a historical result. An order may be cancelled while an earlier result remains valid. Distinct Data Objects allow these lifecycles to be expressed.

4. Tall and wide are views, not metaphysics

A repeated-measure phenomenon can be represented tall:

entity | code | time | value |

or wide:

entity | time | code_a | code_b | code_c |

The tall form supports extensibility and uniform operations; the wide form supports human reading and certain analytical tools. Neither is the phenomenon itself.

Let tall relation be $T(e,c,t,v)$. A wide view for code set $C^{\prime }$ is a pivot transformation

Because $W$ is derived, new codes can be added without altering primary storage. If the wide table is treated as the canonical object, every new observation type becomes a schema change.

Architecture improves when physical shapes are recognised as projections optimised for uses rather than as ontological commitments.

5. Time exceeds the row

Snapshot tables often represent state at extraction time without preserving the events that produced it. This makes historical reconstruction difficult. An active=true row tells us little about when the state began, which event established it, or whether a correction later changed the interpretation.

A bitemporal relation may include valid time and transaction time:

This enables questions about what was true in the domain and what the system believed at a given time. Many platforms do not need full bitemporal modelling everywhere, but they should distinguish event time from ingestion and update time.

The row is a cross-section through time. The domain is a history.

6. Relations beyond foreign keys

Tables represent relationships through keys, but not every relevant relation is a simple foreign-key dependency. Provenance, causation, derivation, temporal precedence, and semantic equivalence may form graphs.

Let Data Objects be vertices $V$ and typed relations edges

Examples include derived_from, supersedes, belongs_to_encounter, fulfils_order, standardises_as, and observed_by_device. Some can be implemented relationally, but the conceptual graph should be explicit.

The point is not that graph databases should replace relational stores. It is that the architecture should not limit its ontology to whatever relations happen to be convenient in one table design.

7. Tables and the culture of legibility Modern administration has long relied on tables because they render populations comparable. The table creates a field in which heterogeneous cases can be aligned under common columns. This is powerful and political. What cannot be columnised may become invisible.

James C. Scott’s discussion of legibility is relevant: states and organisations simplify complex realities to make them administrable. Data tables are instruments of legibility. They enable coordination, but their categories can erase local nuance.

A cultivated data practice therefore asks what the table excludes. Free text, uncertainty, sequence, exceptions, and contested classifications may require supplementary representation. The solution is not to reject tables but to treat them as designed views.

8. Physical optimisation versus semantic stability A platform may store the same Data Object in different physical forms: Delta table, Parquet files, relational table, materialised view, API payload, or event stream. The logical contract should remain stable across these implementations.

Let logical object $D$ have implementations $I_1,\dots ,I_k$. Each implementation is valid if there exists a semantics-preserving encoding

and decoding or interpretation function sufficient for the intended operations. Performance optimisation can then evolve without redefining the object.

This separation mirrors compiler architecture: a high-level language can target different machines because semantics are not identical to one machine representation.

9. A practical modelling discipline Before accepting a source table as a platform object, ask:

• What real or institutional entities does the table conflate?
• Which attributes share the same identity and lifecycle?
• Which timestamps refer to occurrence, recording, or revision?
• Which fields repeat because of denormalisation?
• Is the row an event, a state, a document, or a mixture?
• Which relations are implicit in naming conventions?
• Which consumer view motivated the shape?
• Can the same concept be represented from another source format?

The answer may still justify a one-to-one mapping. The discipline lies in proving it rather than assuming it.

10. A table can be an execution plan Many wide or aggregated tables are better understood as cached execution plans for recurrent questions. They precompute joins, filters, pivots, or windows so that consumers receive predictable performance. This is legitimate, but the architectural status should be explicit: the table is a materialised derivation, not the primary definition of the underlying phenomena.

Let $D$ be the governed object set and $q$ a recurrent query. A materialised table is

where tv records the version and evaluation point. Refresh policy, late-data handling, and invalidation rules become part of the contract. Without them, two materialisations of “the same” view may disagree for reasons hidden from consumers.

Thinking of tables as execution artefacts also clarifies optimisation. Partitioning, clustering, denormalisation, and indexing can change without changing semantic definitions. The platform is then free to produce several physical tables for different workloads while keeping one logical account of the object and metric. Performance engineering becomes a reversible implementation decision rather than an ontological commitment.

Data is not the table that contains it because tables are contingent representations optimised for storage, query,

exchange, or human legibility. A table may contain several objects, several tables may represent one object, and

the same object may need tall, wide, temporal, or graph projections.

A computational Data Platform should respect the relational model while escaping source-shaped thinking. It

defines stable identities, lifecycles, relations, and temporal semantics, then chooses physical forms suited to

each workload. Tables remain indispensable tools. They become dangerous only when their convenience is

mistaken for the natural architecture of the world.

*Conceptual references

Codd, E. F. “A Relational Model of Data for Large Shared Data Banks” (1970). Date, C. J., writings on relational theory. Scott, J. C. Seeing Like a State (1998). Chen, P. P. “The Entity-Relationship Model” (1976).*