19 Benefits of a Decomposition into Domains with Unary Predicates

Predica has a minimal mechanism:

  • uniformity
  • no relation-valued attributes
  • no tuple-valued attributes
  • no possreps
  • no need for relvars
  • no need for n-ary relations in the underlying semantics

The RM works directly with n-ary predicates whereas Predica uses unary predicates. This finer-grained approach has a wide range of significant benefits, including:

  • Improved modularity. Complex domains are decomposed into smaller ones. Key definitions are local to the types they belong to and can be changed without affecting all references, as discussed for composite keys in entity types as logical sorts.
  • Direct cardinality control. Cardinality constraints attach directly to attributes, making them easy to express and modify. In the RM, such changes require structural modifications to relvars, as discussed in the chapter on cardinality.
  • Avoidance of artificial surrogate keys. Some domains that require surrogate keys in the RM do not require them in Predica. The chapter on identity gives an example where a simple change to Predica cardinality constraints becomes a substantial Tutorial D redesign.
  • Natural support for partial information. Decomposition into unary predicates is a game changer for handling incomplete data. The RM becomes cumbersome when pushed toward 6NF, often leading practitioners to introduce NULLs, special marker values, subtype tables, EAV encodings, or other representational workarounds that compromise typing, inference, and constraint checking. Predica naturally supports partial information because attributes have independent unary predicates. Optional information is modelled using cardinality constraints, as discussed in the chapter on cardinality, and queries that reconstruct n-ary relations account for partial information by the way queries work.
  • Clearer semantics for derived information. Because each attribute is a unary predicate, derived attributes and constraints are expressed uniformly as logical definitions. This cleanly separates stored and derived information without procedural machinery, as illustrated by the Person example in event sourcing.
  • Smoother schema evolution. Adding, removing, or changing an attribute affects only one predicate. Structural changes that require table redesign in the RM become local and incremental in Predica; see schema evolution.
  • Alignment with programming models. The decomposition of value domains mirrors object composition and algebraic data types, making Predica a natural bridge between logical modelling and programming languages.
  • Reduced join complexity. Navigation between domains is expressed directly through attributes, avoiding the need for explicit joins for simple traversal. Reconstructing n-ary relations is done only when needed; see navigation.
  • Alignment with high-performance implementations. The logical model allows emphasis of bidirectional navigation between domains, resembling navigation along edges in graph databases, as discussed in pushing relationships down into the entities.
  • Intuitive query formulation. The attributes of domains give rise to navigation paths that are natural to follow when expressing queries; see navigation.
  • High-performance ingestion and flexible constraint layering. Because each attribute is an independent unary predicate, constraints can be relaxed in the base representation to allow very fast ingestion, higher concurrency, and independent updates. Different predicates can even be stored in separate physical databases. More complex constraints are then imposed in derived attributes, which provide a pristine, fully-checked view of the data. This separation avoids the view-update problem and enables both high performance and strong semantics.
  • No view-update problem. In the RM, n-ary relations are stored directly, and views that reconstruct information introduce ambiguity about how updates should be propagated back to base tables. Predica stores only unary predicates, and n-ary relations are reconstructed on demand. As a result, updates always apply to the underlying unary predicates, and the classical view-update problem does not arise.
  • Support for Operational Transformation. Because each attribute is an independent unary predicate, updates are fine-grained and commute naturally. Constraints can be relaxed in the base representation to allow concurrent, distributed updates, while derived attributes impose stricter semantics in the pristine view. This separation provides exactly the conditions required for Operational Transformation: independent updates, conflict-free merging, and convergence without the view-update problem.
  • Zero-latency editing, local replicas, and branching/merging. Because each attribute is an independent unary predicate, updates are fine-grained and commute naturally. This enables Operational Transformation and local replicas that can be edited with zero latency, without pessimistic or optimistic concurrency control. The relaxed base representation allows independent updates and high ingestion rates, while derived attributes impose stricter constraints in the pristine view. The same structure also supports branching and merging of databases in the style of version-control systems such as Git.
  • Ability to record conflicting information. Because cardinality constraints are legality conditions rather than storage restrictions, Predica can record multiple conflicting facts about the same attribute. This is invaluable for high-throughput ingestion, distributed updates, Operational Transformation, and branching/merging workflows. Conflicts are preserved as data and resolved in derived, constraint-rich views rather than being rejected at ingestion time; see Boolean-valued attributes for a simple example.