Who Owns the Truth in the Battle Over Types and Constraints
Fifty years ago, Codd gave us domains and integrity rules, the seeds of type and validity. The industry took the parts it liked, and left the rest on the table. Fifty years later, his successors never escaped the chaos he set out to fix.
I think Codd would have something to say about that.
1. The Relational Foundations
1.1 Codd and the Relational Model
Codd established the formal foundation of the relational model, primarily addressing data representation, independence, and manipulation through relational algebra. Although he introduced foundational concepts such as domains and integrity rules, he did not develop the richer type systems and comprehensive constraint mechanisms that the database industry considered necessary for a complete relational system.
1.2 SQL and the Industry’s Interpretation
But the industry largely implemented SQL-based DBMS, rather than fully relational DBMS, providing practical data management while only partially adhering to the relational principles articulated by Codd. These systems generally retained the closed-world assumption (CWA) of conventional databases, while constraints were often treated primarily as implementation features for maintaining data integrity rather than as fundamental components of the underlying data model.
1.3 Date, Darwen, and The Third Manifesto
Date and Darwen attempted to address these aspects through The Third Manifesto, emphasizing strong typing, user-defined types, and constraints as first-class elements of the model. Their work sought to move beyond the limitations and inconsistencies of mainstream SQL implementations by presenting a more rigorous and coherent relational model in which types and integrity constraints are integral to the model itself. However, the Third Manifesto remained primarily a theoretical specification and did not become a widely adopted foundation for commercial DBMS implementations.
2. The Semantic Web: From Inference to Validation
2.1 RDF/OWL and the Open World Assumption
In contrast, the RDF/OWL data model approached the problem from a different direction, prioritizing flexibility, open-world knowledge representation, and semantic interoperability rather than the strict structure of relational systems. Although OWL supports rich descriptions of types and semantic constraints, these constraints generally describe what can be inferred rather than enforcing database integrity in the traditional relational sense. This reflects the Open World Assumption (OWA) underlying RDF/OWL: the knowledge represented in a graph is potentially incomplete, so the absence of a statement cannot, by itself, be interpreted as evidence that the statement is false. This is fundamentally different from the closed-world orientation of conventional relational databases, where the database is typically treated as a bounded representation of the relevant facts.
2.2 SHACL and Explicit Constraint Validation
SHACL (Shapes Constraint Language) addresses this gap by introducing a dedicated constraint-validation layer for RDF graphs. Unlike OWL, whose axioms are primarily intended to describe semantics and support logical inference under the open-world assumption, SHACL defines explicit conditions that RDF data must satisfy in order to conform to a specified shape. These constraints can express requirements concerning property cardinalities, datatypes, value ranges, class membership, node relationships, and other structural conditions, allowing RDF graphs to be validated in a manner more comparable to database integrity checking.
2.3 The Departure from the Traditional Database Model
The RDF/OWL/SHACL ecosystem, however, represents a significant departure from the traditional database model. Rather than integrating data types, structural constraints, and integrity enforcement into a single transactional data model, it separates these concerns across different layers: RDF provides the graph-based data model, OWL provides semantic vocabulary and logical entailment, and SHACL provides external validation of graph conformance. This separation offers considerable flexibility and semantic expressiveness, but it also introduces substantial conceptual and operational complexity for software engineers who must design, implement, and maintain systems that depend on all three layers working together. Developers must reason simultaneously about graph structure, ontology semantics, open-world assumptions, logical entailment, and constraint validation. Concerns that are partially unified or more tightly integrated within a conventional relational DBMS. In particular, the distinction between what is logically entailed by the knowledge graph and what is explicitly required for data validation can make application behavior more difficult to predict and integrity guarantees more difficult to reason about. The result is a powerful model for representing and integrating knowledge, but one in which responsibilities traditionally unified within the relational DBMS are distributed across multiple semantic and validation mechanisms.
3. Alternative Models Bridging the Gap
3.1 Datomic and TypeDB
Datomic and TypeDB can be viewed as two different attempts to bridge some of these gaps. Both move beyond the conventional relational model while retaining a stronger emphasis on explicit data structure, types, and constraints than is typically found in purely semantic knowledge-representation systems. In contrast to the RDF/OWL/SHACL approach, where data representation (RDF), semantic meaning and inference (OWL), and validation (SHACL) are handled by distinct conceptual layers, Datomic and TypeDB seek to integrate these concerns more closely within the database model itself. They therefore illustrate an alternative direction in which the flexibility of richer data models can coexist with a more explicit and enforceable notion of types and constraints, bringing them conceptually closer to the concerns raised by Date and Darwen. Rather than abandoning the idea that a database should provide an integrated foundation for data integrity, these systems explore how such guarantees might be preserved while moving beyond the rigid table-and-tuple structures of the traditional relational model.
3.2 Datomic: Facts, Integrity, and Temporal Data
Datomic DBMS treats facts as the fundamental unit of stored data. Datomic’s database is a collection of immutable facts, and its history records what has been asserted or retracted over time, making the database inherently temporal and allowing past states of the database to be queried and reconstructed. Rather than updating and overwriting data in place, transactions add new facts or retract existing ones, providing a durable history of how the database evolved. This transaction-oriented architecture makes the transaction itself a first-class part of the data model and allows Datomic to provide strong consistency while preserving historical information. Datomic can also be described as a reflective database system: its schema and metadata are themselves represented as data and can be queried and reasoned about using the same underlying mechanisms as application data. This enables applications and tools to inspect the database’s own structure programmatically rather than relying entirely on external schema definitions.
3.3 TypeDB: A Database Built Around Types
While Datomic is primarily fact-oriented and reflective, with schema and metadata represented in a way that can be inspected and queried as part of the database’s own data model, TypeDB is explicitly strongly typed and schema-driven. Its schema defines entities, relations, and attributes as first-class types, together with the relationships and constraints that govern how they may be combined. Rather than treating types primarily as properties of individual attributes, TypeDB uses a type hierarchy to model the structure and semantics of a domain, supporting inheritance and polymorphism as fundamental aspects of the data model. TypeDB also incorporates reasoning capabilities through TypeQL, allowing derived knowledge and computations to be expressed over its typed data model.
3.4 Unifying Types, Constraints, and Data Integrity
Datomic and TypeDB illustrate a broader alternative approach in which types and constraints are not treated as separate concerns delegated to application logic or external validation layers, but are brought closer to the core of the database model itself. Both demonstrate that richer and more flexible data representations do not necessarily require abandoning strong guarantees about the validity and integrity of stored data. By incorporating mechanisms for expressing data structure, types, relationships, and constraints within the database system, they seek to provide a more unified foundation in which the database itself carries a greater responsibility for defining and maintaining valid states. In this respect, both approaches resonate with the concerns raised by Date and Darwen: the idea that types and integrity constraints should be fundamental components of a data model rather than secondary features layered on top of it.
4. The Broader Database Landscape
4.1 OLTP and NoSQL Systems
Beyond these approaches, the broader database landscape has evolved into a wide range of specialized systems, particularly under the umbrella of NoSQL. Traditional OLTP systems, whether relational or non-relational, prioritize reliable transactional processing, concurrency, consistency, and operational integrity. These systems generally relax or redistribute some of the structural and integrity guarantees traditionally associated with relational databases in exchange for scalability, flexibility, availability, or specialized query capabilities.
4.2 An Increasingly Fragmented Landscape
As a result, the database landscape has become increasingly fragmented rather than converging on a single universal model of types and constraints. Different systems make different trade-offs between schema rigidity and flexibility, transactional integrity and scalability, and closed-world data management and richer forms of semantic reasoning. The result is a spectrum of data models in which the fundamental questions raised by the relational tradition what constitutes a type, what constitutes a valid state, and where constraints should be defined and enforced remain open and continue to be answered differently by each database paradigm.
Comment at TypeDB post
In my view, the lesson from TypeDB, Datomic, and similar DBMS is this: Unlike the SQL/RDBMS world, where strong type systems, constraints, and indexing strategies have become standard practice, these alternative DBMS have never converged on anything comparable. No, it is not a graph database, this is a presentation layout. The database field remains wide open for how type systems, constraints, and indexing should work outside the relational model. Moreover, Datalog, SPARQL, and more recently GQL are not adequate to capture the dynamics involved in building the foundations of such systems. They cannot express how values merge, attributes get reused, schemas evolve, provenance persists, conflicts resolve at write time, or rules and reasoning drive inference over the data. After all, isn’t that precisely why TypeDB built its own query language, TypeQL, rather than adopting Datalog, SPARQL, or GQL. Ultimately, no query standard or storage engine matters in isolation. It’s the system as a whole that counts !!!