Is this the same as a machine-learning model?

No. It represents data concepts and relationships rather than learning prediction parameters from examples.

Must every enterprise model be relational?

No. The shared business understanding can inform relational, document, graph and other implementations.

Can different departments retain different meanings?

Yes, when those meanings are genuinely distinct and explicitly named or mapped. The goal is intelligibility, not false uniformity.

AI Glossary / Data engineering and architecture / Intermediate

Enterprise data modeling

Definition

Enterprise data modeling is the practice of describing the important data concepts, relationships and rules across an organization. It creates a shared view of information such as customers, products, agreements and events, helping separate business meaning from individual application designs.

What it means

Different systems often use different words for related concepts. A sales application may refer to accounts, a service application to clients and a billing application to payers. The model asks whether these represent the same entity, distinct roles, or different things altogether.

The enterprise perspective looks across those boundaries. It does not require every system to use one giant database or identical tables. Instead, it provides definitions and relationships against which local designs and exchanges can be understood.

Definitions matter as much as diagrams. A line labeled “owns” is incomplete if nobody can explain whether it means legal ownership, operational responsibility or a temporary assignment. The model should capture the distinctions needed for actual business decisions.

How it works

Modelers identify subject areas and work with business specialists to define relevant entities. They describe attributes, identifiers, relationships and constraints, then test those descriptions against representative business situations.

A conceptual view emphasizes major concepts and their relationships. A logical view adds detail while remaining independent of a particular database implementation. Physical designs translate requirements into structures suited to selected technologies. Terminology and boundaries vary between modeling methods, so each deliverable should state its scope.

Mapping source fields to shared concepts exposes differences. Two identifiers may refer to the same customer population but require a cross-reference; two fields called status may describe unrelated lifecycles. Exceptions should remain visible rather than being forced into a misleading common label.

The model evolves as the business changes. Ownership, versioning and links to implemented data help keep it useful. Agreement on a model does not automatically repair existing records or prove that every application enforces its rules.

Three practical examples

A subscription business distinguishes the person using a service from the organization paying for it, improving the meaning of customer reports.
A manufacturer models product types separately from individual manufactured items so maintenance histories attach to the correct physical units.
An AI assistant uses documented concepts and relationships to interpret business questions, with generated queries checked against actual permitted data structures.

Think of it this way

Think of a shared map legend. Different maps can use different scales and layouts while agreeing on what a railway station or boundary means. The legend makes comparison possible without requiring one enormous map for every purpose.

The analogy is limited because enterprise concepts are negotiated and change over time. A shared model must sometimes preserve multiple legitimate meanings rather than pretending that one label resolves every disagreement.

Worked example

Separating a person from an account

An invented organization has 80 people and 100 service accounts. Sixty people each hold one account, and twenty people each hold two: 60 + 40 = 100 accounts. Every account in this simplified example has exactly one account holder.

A report that counts account records and labels the answer “customers” returns 100. A report that counts distinct people returns 80. Neither number is inherently wrong; the label and business question determine which is appropriate.

The enterprise model therefore distinguishes Person from Service Account and defines their relationship. If 30 accounts close, that alone does not establish that 30 people left: some account holders may retain another account.

This simple model still has limits. Joint accounts, organisational holders and changes of ownership would require additional relationships or entities. Modeling explicitly identifies those requirements instead of assuming that every business situation fits the first example.

Illustrative case study

A fictional facilities company combines maintenance and purchasing data. Purchasing uses “asset” for a group of items bought together; maintenance uses it for an individually serviceable unit. An early AI-generated report joins the two identifiers as though they described the same thing.

The data team models purchase line, equipment type and physical equipment separately. It documents how several physical units can originate from one purchase line and how installation locations change over time. Source mappings preserve those distinctions.

The company then checks representative queries with purchasing and maintenance staff. Its shared model helps explain why cost per purchase line differs from cost per maintained unit. The model does not magically fix missing serial numbers, so the team tracks those data-quality exceptions separately. This case is fictional.

Common misconceptions and mistakes

Enterprise modeling means centralizing all data. Shared meaning can support distributed implementations.
Matching field names establish equivalence. Business definitions and relationships must be compared.
The most detailed diagram is always best. Excessive detail can hide the concepts a particular audience needs.
A signed-off model guarantees clean data. Actual records and system behavior still require validation.

Business use

Use enterprise data modeling where several initiatives need consistent interpretations of shared information. It can inform integration, reporting, application replacement and AI projects by exposing semantic disagreements before implementation makes them expensive to change.

Start with valuable cross-functional questions and the concepts they depend on. Assign people who can resolve definitions, document unresolved issues and connect the model to source mappings. Deliver useful subject-area work incrementally while checking its fit with the wider view.

For AI, a model can provide structured context about what business terms mean. It is not a trained predictive model, and giving it to a language model does not guarantee correct answers. Validation must still cover actual joins, historical rules and access permissions.

Check your understanding

Two systems both contain a field called customer_id, but one identifies households and the other individuals. Is renaming both fields to the same standard enough?

Answer: No. The underlying entity meanings differ. Model the distinction and define the relationship or mapping needed for the intended use.

Related terms

Conceptual data model
Logical Data Model
Data architecture
entity
relationship
business glossary
master data management

Learn next

Read entity - relationship modeling and business glossary. Choose a term used by two departments and write its definition, identifier, relationships and historical rules before deciding whether the meanings can be shared.

Sources

IBM, What Is Data Modeling?: https://www.ibm.com/think/topics/data-modeling. Primary vendor explanation of conceptual, logical and physical modelling.

IBM documentation, Logical data model assets: https://www.ibm.com/docs/en/iis/11.7.0?topic=types-logical-data-model-assets and Overview of data modeling: https://www.ibm.com/docs/en/ida/9.1.1?topic=modeling-data. Primary descriptions of entities, relationships, subject areas and implementation mappings. Examples and counts are original illustrations.

Previous: Enterprise cognitive system Next: Enterprise data planning