15 The Information Principle

Chris Date’s “Information Principle”, originating in the work of E.F. Codd, states that all information in a relational database must be represented in exactly one way: as explicit data values within tuples in relations. The intent is to ensure a single, uniform representational mechanism for information, free of ad-hoc devices such as pointers, flags, or hidden structures.

However, the principle becomes less constraining once complex data values are permitted within tuples. Date and Darwen explicitly allow tuple-valued attributes, relation-valued attributes, and user-defined types with possreps. Under such a permissive notion of “value”, it becomes formally possible to embed an entire object-oriented database as the value of a single attribute in a single tuple of a single relvar, while still claiming to adhere to the Information Principle. This is clearly not what they intended, and they would certainly reject such a design as contrary to the spirit of the relational model.

Indeed, their aim was to rule out representational mechanisms such as:

  • pointers
  • arrays
  • nested documents
  • object graphs
  • NULLs
  • hidden metadata
  • physical ordering

For good reasons, Date and Darwen argue that the relational model should play a central role in any information system. But in practice, the strength of the Information Principle depends on how “simple” the permitted data values are. Once values may be arbitrarily complex, the principle relies on the informal and historically vague notions of First Normal Form and “atomicity” that Codd originally invoked. There seems to be no way around this: the Information Principle only has real force if the allowed values are sufficiently simple.

Predica's information principle

It is not immediately obvious whether Predica should be regarded as adhering to the Information Principle. Predica does not expose relations or tuples in its surface syntax, and so one might think it violates the principle by abandoning the tuple-based representation of information.

Predica retains the intent of the Information Principle but states it in terms of unary predicates:

The information principle: Every materialised value in a Predica database is used to instantiate a unary predicate, down to the level of simple values such as integers, strings, and values of enumerated types, yielding a true proposition about the modelled world.

Each attribute introduces a unary predicate, and the extension of the attribute is the set of values for which that predicate holds. Information is therefore represented as facts of unary predicates, without alternative representational mechanisms. In this sense, Predica preserves the original intent of the Information Principle at least as faithfully as the classical relational model, and arguably more so.

Several corollaries follow.

  • Predicates as the foundation. Attributes are unary predicates. Their extensions are true predicate instances.
  • Separation of schema from values. Relation values do not carry headings or types. The schema defines attribute names, domains, and constraints; relation values are pure sets of tuples. This keeps the algebra simple and avoids artificial distinctions between relations that differ only in annotations.
  • No primitive n-ary relvars. N-ary relational structure is recovered by composing unary predicates.
  • Full decomposition. Multi-attribute structure is decomposed into predicate instances and recovered by composition.

No hidden identifiers

Another corollary of the information principle is that Predica does not use memory addresses, object identifiers, or other hidden handles as logical identity. Hidden identifiers are not values used to instantiate predicates about the modelled world; they are representational machinery.

Several consequences follow.

  • Entities have keys. Entity identity is stated by declared keys and constraints, not by physical or hidden object identity.
  • Entity and value types. Entity types represent identified things that exist in time and space. Value types represent pure values with no independent identity. This distinction localises identifiers, avoids foreign-key proliferation, and supports clean modelling of real-world domains.
  • Object orientation is rejected. Predica does not model values as objects with hidden identity that receive messages through object handles. Dynamic dispatch through object identifiers is not part of the logical model.

Predica entity types are not OO objects

Predica’s entity types resemble OO classes in surface syntax, but they do not behave like OO object types. Their instances have explicit logical identity defined by keys, never hidden object identity.

This distinction matters. In OO, there are two very different notions of “class”:

  • Reference classes: objects with identity, pointer semantics, and mutability (Java, C#, Python, Smalltalk).
  • Value classes: immutable records with no hidden identity (Rust structs, Swift structs, Haskell records, ML records, C++ POD types).

Predica entity types are closer to the second category. They have explicit keys and:

  • no hidden identity
  • no pointer semantics
  • no aliasing
  • no mutability
  • no object-identity behaviour

The correct analogy is therefore: 

Predica entity types are like immutable record types
with explicit logical keys, not like OO objects.

Predica resembles OO only in notation, not in semantics. It embraces the clarity of class-like syntax while avoiding hidden identity, pointer semantics, and mutable object state.