Information Model, Data Model, and Data Schema - TX
Information Model, Data Model, and Data Schema
This page defines three complementary layers used to model the **physical reality** of store data within systems and to exchange data across systems.
Information Model
- Definition
A formal and unambiguous representation of physical reality, expressed in precisely defined concepts, attributes, relationships, and constraints. It defines meaning, not storage or syntax.
- Key characteristics
- Single-topic attributes (one semantic dimension per attribute).
- Controlled synonyms; no homonyms (same word for different meanings).
- Stable and universal (independent of system, time, or place).
- Logical structure that mirrors the real world (e.g., a Product + Sales Packaging ⇒ Sales Unit (ISU).
- Purpose
Create a shared understanding of reality across organizations and systems.
Data Model
- Definition
The system-specific implementation of the Information Model, defining how each concept is represented, stored, and secured (fields, types, keys, code lists, relationships, permissions).
- Key characteristics
- Every field maps to a single concept from the Information Model.
- Fields are atomic (one property per field) and placed at the correct hierarchy level.
- Includes operational metadata (names, datatypes, validation, access rules).
- Purpose
Realize the Information Model in software while preserving semantic purity.
Data Schema
- Definition
A machine-readable specification for exchanging data between systems with different data models. It defines structure, syntax, and validation for transport — not meaning.
- Key characteristics
- Specifies formats, required/optional fields, and validation rules.
- Enables interoperability while preserving the semantics defined by the Information Model.
- Common exchange types: JSON, XML, and Spreadsheet templates (Excel/CSV).
- Purpose
Ensure accurate, interoperable data exchange across the value chain.
Summary Table
| Layer | What it Defines (short) | Purpose | Typical Artifacts | Common Exchange Types |
|---|---|---|---|---|
| Information Model | Meaning (concepts, relations, constraints) | Shared understanding of physical reality | Glossary, ontology, UML class diagrams, relationship rules | N/A (conceptual) |
| Data Model | Implementation (fields, code lists, hierarchy) | Operational storage & validation in a system | Entity/attribute lists, database schemas, API field specs | N/A (system-internal) |
| Data Schema | Structure & syntax for transport | Interoperable exchange between systems | JSON Schema, XML Schema (XSD), Spreadsheet templates | JSON (.json), XML (.xml), Excel/CSV (.xlsx/.csv) |
Terminology Rules
- Use a **single meaning per term** (no homonyms).
- Allow synonyms, but map them to one canonical concept.
- Keep attributes **uni-dimensional** (do not combine multiple concepts like Color+Opacity).
- Separate **universal, physical facts** from **contextual conclusions** (e.g., local grades or policy thresholds).
