Enterprise Data Modelling¶

The organizational practice of creating and governing a shared conceptual model of enterprise data—its business entities, meanings, relationships, rules, and authoritative vocabulary—across systems and projects.

Version: v1 · 2026-09-28 · History
Domain-specific #: 9261
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Information Systems, Enterprise Data Architecture, Data Management → Computer Science & Software Engineering
Aliases: Enterprise Data Modeling, EDM Practice, Enterprise Information Modelling

Core Idea¶

Enterprise data modelling is semantic coordination at organizational scale. It identifies what the business means by its key data and how those concepts relate before technology-specific schemas fragment the vocabulary.

The model becomes useful through governance and mapping. Diagrams and dictionaries must connect to accountable stewards, decision processes, integration contracts, physical systems, and managed evolution.

Structural Signature¶

Sig role-phrases:

Business concepts — Define entities, events, measures, and meanings important across the enterprise. It is semantic content. Counterfactual: Table names alone do not establish shared meaning.
Relationships and rules — Express identity, cardinality, lifecycle, and constraints. It is structure. Counterfactual: A glossary without relations is not a full model.
Enterprise scope — Crosses departments, applications, and local vocabularies. It is boundary. Counterfactual: One project's schema is not automatically enterprise-wide.
Representation artifacts — Make the model inspectable through diagrams, dictionaries, and schemas. It is externalization. Counterfactual: No single notation has to carry every level.
Stakeholder governance — Negotiates definitions, ownership, and approved change. It is authority. Counterfactual: A model without stewardship quickly diverges.
Mappings to implementations — Relate shared concepts to physical databases, messages, and services. It is operational link. Counterfactual: The enterprise model should not merely duplicate one legacy schema.

What It Is Not¶

It is not merely one database schema.
It is not a diagram with no governance.
A data catalog is not necessarily an enterprise model.
One canonical XML schema cannot capture every conceptual and physical layer.
Closest near-miss. A canonical integration model standardizes exchange representations; an enterprise data model can inform it but also defines enduring business semantics independent of one interface.

Scope of Application¶

Data governance. Assigns definitions, ownership, and change authority.
Systems integration. Maps heterogeneous applications to shared semantics.
Analytics. Stabilizes dimensions, measures, and lineage.
Architecture planning. Guides platform and domain boundaries without dictating one implementation.

Clarity¶

State organizational scope, modelling level, concepts and definitions, identifiers, relationships and cardinalities, business rules, notation and repository, source systems, local-to-enterprise mappings, steward and decision rights, extension policy, versioning, lineage, review cadence, quality measures, and explicit exclusions.

Manages Complexity¶

Large organizations contain overlapping terms, duplicated identities, local rules, acquisitions, and legacy schemas. A shared model must reconcile enough meaning for interoperability without becoming either an abstract poster or a centralized bottleneck.

Abstract Reasoning¶

Set enterprise scope and priority decisions the model must support.
Elicit business concepts and rules from processes, records, and stakeholders.
Reconcile identities, synonyms, and conflicting definitions.
Represent relationships and map them to local systems without copying implementation accidents.
Govern ownership, versions, extensions, and measurable adoption over time.

Knowledge Transfer¶

Conceptual modelling and governance transfer across organizations, but entities, authority, regulation, and system mappings are enterprise-specific. A template industry model becomes authoritative only through local validation and stewardship.

Examples¶

Canonical¶

A bank defines shared Party, Account, Agreement, and Transaction concepts, their identity and lifecycle rules, assigns stewards, and maps CRM, lending, and payment schemas to the governed logical model.

Mapped back: concepts → shared business entities; relations → identity and lifecycle; scope → three system domains; governance → named stewards; mappings → local schemas.

Applied / In Practice¶

Reverse-engineering the tables of one payroll application yields a useful physical model but not an enterprise model when other domains and shared semantics are absent.

Mapped back: artifact → one schema; scope → payroll only; governance → absent; verdict → application model.

Structural Tensions¶

T1 — Enterprise Consistency versus Local Fitness. Shared definitions enable integration while business units need specialized concepts and pace.

Diagnostic: Which core is mandatory and where are extensions legitimate?

T2 — Semantic Stability versus Organizational Change. Durable identifiers and meanings support history while products, regulation, and structures evolve.

Diagnostic: How are changes versioned and mapped without breaking lineage?

Structural–Framed Character¶

Enterprise Data Modelling is structural as governed organization-wide data semantics and framed by cross-system mapping and stewardship.

Structural Core vs. Domain Accent¶

The broad pattern is constructing a shared representation across local views. Enterprise data adds business entities, schemas, dictionaries, ownership, integration, lineage, and change governance.

This entry presupposes Schema.

Approved enterprise-modelling root. No frozen parent entails organization-wide governed data semantics.
Related — conceptual data model, logical data model, physical schema, canonical data model, data dictionary, data catalog, and ontology. They are levels, artifacts, integration form, repository, and richer semantic neighbor.

Relationships to Other Abstractions¶

Current abstraction Enterprise Data Modelling Domain-specific

Parents (1) — more general patterns this builds on

Enterprise Data Modelling presupposes Schema Prime

Enterprise Data Modelling presupposes Schema: the parent's defining role is necessary to the child's frozen mechanism or criterion.

Hierarchy path (1) — routes to 1 parentless root

Enterprise Data Modelling → Schema → Abstraction

Neighborhood in Abstraction Space¶

Enterprise Data Modelling sits in a crowded region of the domain-specific corpus (31^st percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Organizational Patterns & Management Concepts (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Physical data model. Tell: Specifies storage details for a particular implementation.
Data catalog. Tell: Inventories assets and metadata but may not reconcile concepts.
Enterprise architecture. Tell: Covers capabilities, applications, and technology beyond data semantics.
Ontology. Tell: Can provide formal semantics but is not identical to the organizational practice.

References¶

Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Enterprise_data_modelling (revision 1066543804).
Preserved source candidate: http://www.tdan.com/view-articles/5205

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.