Data Model¶
Artifact — instantiates Ontology Clarification
Translates ontology decisions into tables, objects, fields, identifiers, or constraints used by information systems.
A Data Model is the operational schema that turns a clarified ontology into the concrete structures a running information system uses: tables and objects, fields and identifiers, keys, value sets, and constraints. Its defining move is to make the ontology executable — to commit each entity to a stored form precise enough that software can create, relate, and validate it. That precision is bought by trading away the conceptual neutrality of a domain model: a data model no longer floats above implementation, it is the implementation's account of what exists, expressed in whatever a database or type system can enforce. Its central hazard is the flip side of its power — implementation capture, where the schema quietly starts dictating what the domain is allowed to be because reality now has to fit the columns.
Example¶
A retail company is building the order-management database behind a new checkout. The ontology work has settled the conceptual terms — Order, Customer, Product, Payment — but the data model is where those terms have to become something a machine can store without contradiction, and that forces decisions nobody had made out loud. What counts as an Order? The team writes the boundary into the schema: an abandoned cart is not an Order (it has no placed_at timestamp and fails the constraint); a zero-dollar comp is an Order (it just has a total of 0). Then they walk the edge cases and give each a defined home: a guest checkout has no account, so customer_id is nullable and a separate guest_email field carries the contact; a partial refund needs its own refund rows rather than mutating the order total; a product discontinued after purchase must still resolve, so the line item snapshots the price and name at sale time instead of pointing at a live product record.
Kept in the disciplined split between the conceptual/logical model and the physical schema,[n1] each of these is recorded as a deliberate schema decision, not an accident of whoever wrote the migration. The result is a database that cannot hold an order the business considers invalid — and an explicit register of the awkward cases, so the next engineer inherits the reasoning instead of rediscovering it in a production incident.
How it works¶
- Give each entity a concrete home. Every entity handed over by the conceptual model becomes a table or object with typed fields and a stable identifier the system can reference.
- Encode the boundary as constraints. Inclusion and exclusion rules become keys,
NOT NULL, enumerations, and check constraints, so the schema itself refuses data that falls outside the defined scope. - Register each edge case as a decision. The nulls, the special values, the orphan and one-off situations are each resolved with an explicit structural choice and written down, not left to interpretation.
- Guard the mapping back. Every field is traceable to a conceptual term, so the schema stays an implementation of the ontology rather than a rival to it.
What distinguishes it from a conceptual model is that it commits to enforceable form; from a semantic schema, that it serves one system's storage rather than machine reasoning across many.
Tuning parameters¶
- Normalization level — a highly normalized schema protects integrity and kills redundancy but costs joins and performance; denormalizing is faster to read but lets the same fact drift out of sync in two places.
- Constraint strictness — enforcing rules in the database rejects bad data at the door but makes the schema rigid; pushing rules into the application is flexible but lets invalid states slip into storage.
- Nullability policy — permissive optional fields absorb messy reality easily but hide missing-data problems; strict non-null fields force clean input but choke on legitimate edge cases.
- Identifier strategy — natural keys are meaningful and human-legible but break when the real-world value changes; surrogate keys are stable and opaque but push meaning into other columns.
When it helps, and when it misleads¶
Its strength is turning agreements into enforcement: once the boundary is in the schema, the system cannot store an order, patient, or account the business has declared impossible, and the edge-case register means the hard situations are handled on purpose rather than discovered in an outage. It is the right mechanism exactly when the ontology has to become operational in software or analytics.
Its failure mode is implementation capture — the schema hardens into the de facto ontology, and because changing a live database is expensive, the domain slowly contorts to fit the columns instead of the reverse. A tidy schema also lends false precision to distinctions that were never really settled. The classic misuse is letting a table structure invented for last quarter's feature silently define a core term for the whole company. The discipline that guards against it is to keep the conceptual model separate and authoritative, and to require every schema change to trace back to a domain decision rather than the other way around.
How it implements the components¶
A Data Model fills the archetype's operational slots — the parts that only exist once the ontology has to run:
boundary_condition— inclusion and exclusion rules encoded as keys, constraints, and valid value sets, so scope is enforced by the schema itself.edge_case_register— each awkward case (guest checkout, partial refund, discontinued product) resolved as an explicit, recorded structural decision rather than left ambiguous.
It does not define the conceptual entities, categories, and relations it is implementing (entity_inventory, category_definition, relation_definition — that's Domain Model), nor encode meaning for machine reasoning and cross-source integration (term_source_map, translation_crosswalk — that's Semantic Schema); it operationalizes a model handed to it rather than negotiating one.
Related¶
- Instantiates: Ontology Clarification — the Data Model is the operational schema the clarification's decisions run on.
- Consumes: Domain Model supplies the conceptual entities, categories, and relations this schema commits to storable form.
- Sibling mechanisms: Domain Model · Semantic Schema · Ontology Review Workshop · Concept Map · Ontology Map · Taxonomy · Glossary
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: The model externalizes ontology decisions as entities, stable identifiers, typed fields, keys, constraints, edge-case choices, and conceptual traceability, so its operative form is an information-system specification.
Nearest alternative: Structure, Architecture & Configuration — Implemented tables and objects become system structure, but the mechanism described is the formal model that specifies that structure.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Database and software design cohered conceptual, logical, and physical data models that represent entities, fields, identifiers, relations, and constraints in executable storage structures.
Related originating lineages:
- Library & Information Science — Knowledge organization supplied entity and relationship modeling and concern for correspondence between conceptual terms and stored representation.
Review resolution: Database and software design established formal data models; information organization contributes a genuine documentary and semantic lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The most common trouble with a Data Model is not a bug but a boundary crossed silently: because it is the artifact that actually runs, its incidental storage choices acquire the authority of decisions no one made. Separating the conceptual model from the physical schema, and mapping between them on purpose, is the whole defense against that.
[n1] Standard data-management practice distinguishes conceptual, logical, and physical data models (as in the ANSI/SPARC three-schema architecture): the conceptual layer states what exists, the logical layer structures it, and the physical layer commits it to a specific technology — keeping them distinct is what prevents storage decisions from silently redefining the domain. ↩