The Logical Data Model: The Bridge Between Ontology and Physical Schema

Abstract. Enterprises repeatedly confuse three distinct concerns — the meaning of data, its structure, and its storage. This paper argues that the logical data model is the indispensable bridge that carries business semantics inherited from the ontology and conceptual layers into a rigorous, technology-neutral structure that a physical schema can then implement. Collapsing this layer, as some practitioners advocate, reintroduces the tight coupling that data architecture exists to prevent.

The Layered Problem: Meaning, Structure, and Storage

Every data system must answer three questions that are easy to conflate: What do these concepts mean? How are they organized? How are they stored? DAMA-DMBOK2 frames data modeling itself as "the process of discovering, analyzing, and scoping data requirements, and then representing and communicating these data requirements in a precise form called the data model," noting that this process "may include a conceptual, logical, and physical model" (DAMA-DMBOK2, Ch.5, p.124). These are not stylistic variants of one artifact; they are separations of concern.

The separation is not new. DMBOK traces the three levels to the ANSI/SPARC three-schema approach of 1975, which distinguished the Conceptual (real-world view), External (user subsets), and Internal (machine view) schemas, observing that "these three levels most commonly translate into the conceptual, logical, and physical levels of detail, respectively" (DAMA-DMBOK2, Ch.5 §1.3.5, p.144-145). The ANSI/SPARC architecture was engineered precisely to deliver logical and physical data independence, insulating business meaning from storage decisions.

The Ladder: From Open-World Meaning to Technology-Specific Storage

DMBOK positions the ontology at the top of the meaning stack. "An ontology is a type of taxonomy that represents a set of concepts and their relationships within a domain," providing "the primary knowledge representation in the Semantic Web" through RDFS and OWL (DAMA-DMBOK2, Ch.9 §1.3.2.9, p.314). Critically, DMBOK identifies two differences in kind between an ontology and a data model: in an ontology "entity, attribute, and content concepts can be completely mixed," and it operates under an open-world assumption, where "possible relationships are inferred," whereas a data model operates under a closed-world assumption — "what is defined is what is known - and nothing else" (DAMA-DMBOK2, Ch.9 §1.3.2.9, p.314-315). This aligns with the W3C's definition of an ontology as a formal, shared conceptualization for semantic interoperability, with OWL supplying classes, properties, and axioms for machine inference (W3C OWL).

Beneath the ontology sits the conceptual model, which "captures the high-level data requirements as a collection of related concepts... only the basic and critical business entities" (DAMA-DMBOK2, Ch.5 §1.3.5.1, p.145). Then comes the logical model: "a detailed representation of data requirements... still independent of any technology or specific implementation constraints," which "often begins as an extension of a conceptual data model" (DAMA-DMBOK2, Ch.5 §1.3.5.2, p.146). Here attributes are made atomic — each "should contain one and only one piece of data (fact) that cannot be divided into smaller pieces" (Ch.5 §2.2.1.2, p.155-156) — relationships are normalized into stable structures ("the term normalized model usually means the data is in 3NF," Ch.5 §1.3.6, p.150-151), and primary, alternate, and associative keys are assigned. Finally the physical model "represents a detailed technical solution, often using the logical data model as a starting point," and is "built for a particular technology" (DAMA-DMBOK2, Ch.5 §1.3.5.3, p.148).

Why the Logical Model Is the Bridge

The logical layer is where meaning becomes engineerable structure without yet surrendering to any platform. It inherits vocabulary directly from the semantic layers: DMBOK's entity-aliasing convention names a concept at the conceptual level, an entity at the logical level, and technology-specific names at the physical level (Ch.5, p.143), while controlled vocabularies "should be aligned with the entity names and definitions in an enterprise conceptual data model" (Ch.9 §1.3.2, p.311). It then renders that inherited meaning as normalized, atomic, key-anchored structure — the closed-world discipline the physical model requires. Data architecture exists to "establish the semantics of an enterprise, via a common business vocabulary" (Ch.4 §1.2, p.100); the logical model is the artifact that carries that vocabulary across the meaning-to-storage divide. Practitioners reach the same conclusion, describing the logical model as the contract between business and technical implementers (Erwin, ER/Studio, ScienceDirect). International standards reinforce the split: ISO/IEC 11179 separates metadata meaning from bit-level representation, and academic work (Spyns, Meersman & Jarrar 2002; Guarino 1998) treats ontology and data modeling as complementary layers, with formal ontology informing — not replacing — the modeling pipeline.

Refuting the Dissenters

Two challenges deserve direct answer. Pascal Desmarets (Hackolade, 2018) urges skipping logical modeling to go conceptual-to-physical for NoSQL and agile delivery. But eliminating the logical layer collapses the meaning-translation tier and reintroduces exactly the tight coupling of business semantics to storage that ANSI/SPARC's three-schema architecture and DMBOK's three levels were designed to prevent; short-term agility becomes long-term semantic drift and technical debt. Timbr.ai's marketing claim that ontologies can replace data modeling conflates the ontology's open-world expressive richness with data modeling's distinct closed-world concern for structural and storage optimization. DMBOK's two-differences analysis (Ch.9 §1.3.2.9, p.314-315) settles the point: these are different in kind, and therefore complementary layers — not substitutes.

Conclusion

The ontology answers what things mean; the physical schema answers how bits are stored. Between them, the logical data model answers how meaning is structured — atomically, normally, and independent of technology (DAMA-DMBOK2, Ch.5, p.146). Remove it and the two ends fuse, sacrificing the data independence that half a century of architecture practice has defended. The logical data model is not optional scaffolding; it is the load-bearing bridge.

References