Conceptual data model

CDQ's conceptual data model is the business view of the master data that CDQ services validate, match, enrich and monitor. It groups that data into 5 domains with 37 entities, The domains are Business Partner, Payment, Product, Location and Certificate. The Reference Domain Object Model (RDOM), CDQ's technical standard for how its services structure and name the data, realizes them with its 501 concepts.

Domains and entities

Each domain is built around one main entity, such as the bank account in Payment, and models its own entities with their attributes, relationships and value sets. Each domain page shows the entities of the domain in a diagram of their own.

Domain	Description	Entities
Business Partner	Organizations and persons, their identifiers, relationships and contracts.	Business Partner, Name, Legal Form, Identifier, Tax Registration, Business Partner Status, Classification, Contact Point, Business Relationship, Contract, Contract Party, Contract Item
Payment	Bank accounts, the financial institutions holding them, their holders and their verification.	Bank Account, Account Holder Relationship, Financial Institution, Bank Branch, Account Verification, Payment Evidence
Product	Canonical products, organization-specific materials, trade items and product structures.	Product, Material, Trade Item, Product Identifier, Product Attribute, Product Classification, Product Relationship, Bill of Materials, Product Partner Relationship, Material Site Assignment
Location	Addresses, sites, geolocations and administrative areas.	Location, Address, Geolocation, Administrative Area, Site
Certificate	Certificates, licences, permits and accreditations with their issuers and scope.	Certificate, Certification, Issuer, Certificate Scope

Scope and design principles

The model is conceptual, SAP-aligned and minimal: it holds only the entities and relationships that have a clear link to a data quality rule or to external reference data. It is not an enterprise data model, an SAP data model or an ERP schema. It is organized in 5 domains, the 37 entities within them, and the attributes, relationships and value sets that describe each entity (Elements of the conceptual level).

Ten design principles decide what enters the model and where it sits. An entity or attribute that fails one of them stays out, even when SAP has a field for it.

1

Service value

Every entity and attribute has a credible path to customer value: CDQ can validate or enrich it against reference data, monitor it with a rule, or cannot act safely on a finding without it.

2

Reference data first

Entities that authoritative external sources can confirm come first: registers, GS1, bank directories, certification registers, classification systems, compliance lists.

3

Entities, not capabilities

Domains are families of entities. Validation, matching, enrichment, monitoring, compliance and fraud prevention act on them and are never domains.

4

Independent identity

An entity stands on its own when it has an identity, a lifecycle and relationships independent of other entities. Identity justifies an entity, not automatically a domain.

5

One representation, reused

Each entity exists once and is shared by all services, built from the patterns the business partner model already proves: typed names, identifiers with issuer and status, classifications with version, status with validity, typed relationships, links to the source record. These patterns guide the modeller. They are not model elements.

6

SAP-aligned, not SAP-defined

Every entity maps naturally to SAP terms such as Business Partner, Material Master, plant and bank details, through canonical identities and explicit source mappings. SAP tables and views never shape the model.

7

Facts apart from assessments

Business data, reference data, evidence and service results are four kinds of information: an IBAN, its verification and a fraud score are different things.

8

Minimal scope

No transactional processes, workflows or ERP coverage for its own sake. Transactions enter only as evidence a service needs, such as an open purchase order behind a duplicate supplier.

9

Provenance and validity

Reference data and results carry source, date and validity. For identifiers, certificates and monitoring this is part of being correct.

10

Meaning, not message structure

Domains and entities define meaning and ownership. RDOM and the systems built on it realize them by embedding or reference and are mapped to concepts, not restructured to match them (Reference Domain Object Model).

Each domain models its own entities

There is no shared layer of concepts or entities. Each domain models the entities it needs explicitly. Identifier in Business Partner and Product Identifier in Product, for example, are separate entity types. The similarity is accepted on purpose: they have different issuers, rules and reference data, so modelling them separately is precision, not redundancy. Merging them into one generic entity would lose meaning.

This follows conceptual modelling, which models entity types as they are, ISO/IEC 11179, where the object class determines what a property means, and Domain-Driven Design, which accepts similar concepts in different contexts. The real risk is drift, the same idea modelled inconsistently across domains. Design principle 5 is the rule against it.

Source, Evidence, Assessment, Finding, Event and Case are not part of this model either. They are what CDQ's services produce about records (provenance, results and follow-up), belong to the capability side and refer to records of the five domains. Design principle 7 means they must not be mixed into domain entities, not that this model defines them.

What is not a domain

Validation, matching, enrichment, monitoring, compliance, fraud prevention and data sharing are capabilities: they act on entities and their records and are never domains.

Candidate	Decision	Why
Risk, compliance, fraud	Capabilities producing Assessments and Findings	They evaluate records from several domains. An entity does not become a risk entity because a risk service evaluates its records. The findings, assessments and evidence these services produce refer to records of the five domains but are not part of this model.
Transaction	Evidence only	An open purchase order or payment matters only as evidence behind a finding, never as an entity to master.
Contract	Entity in Business Partner	Its identity comes from its parties.
Asset	Excluded	Its defining data is organization-specific with no external reference data. Its verifiable aspects are covered by Product, Location, Business Partner and Certificate.

Industry scenarios

Ten standard situations from CDQ's main industries (machinery, logistics, retail, chemistry and pharma) walked through the entities and relationships of the model. Each card shows the path through the model, what CDQ checks along it, and how the model handles the case. Read each path from left to right, in the direction of the relationships. Small text in brackets gives the role or an example.

All ten scenarios run on existing entities. Transactions such as sales orders and shipments appear only as evidence, and decisions such as export licences are capabilities. Three refinements follow from them:

• Business Relationship needs "brand of", "franchise" and "legal successor" besides ownership and hierarchy. The relation types in the RDOM are hierarchy-oriented today (for example DIRECT_LEGAL_RELATION and COMMERCIAL_ULTIMATE), so the value set is extended in the conceptual model first.
• Product Partner Relationship applies to Product as well as Material. Manufacturer and brand owner are facts about the canonical product, supplier and customer are the client's view.
• Certificate Scope stays simple. One certificate with several scopes covers a company and its sites, and each scope has exactly one subject.

1Machinery

Spare part from the original manufacturer

Maintenance orders a replacement part. The same part exists under several material numbers because it arrives through the manufacturer and two distributors.

In the model

Material (spare part) → represents → Product → has → Product Identifier (manufacturer part number)
Material → has → Product Partner Relationship (manufacturer, supplier) → with → Business Partner
Product → spare part of → Product (the machine)

What CDQ checks

Resolve the manufacturer to a legal entity. Find materials that represent the same product. Flag parts whose machine is obsolete without a successor.

How the model handles it

Fits. Duplicate parts are several materials that represent one product. "Spare part of" is a type of Product Relationship, not a new entity.

2Machinery

Exporting a machine with a controlled component

A machine containing a dual-use component is sold to a customer outside the EU.

In the model

Contract Item → refers to → Product → classified as → Product Classification (export control)
Business Partner (customer) → acts as → Contract Party
Business Partner → uses → Address (delivery) → within → Administrative Area (country)

What CDQ checks

Validate the export control classification against the current list. Derive the destination country from the delivery address. Screen the customer.

How the model handles it

Fits. The licence decision is a compliance capability, and the sales order is evidence only. The model supplies the facts both need.

3Logistics

Onboarding a new carrier

A road carrier is onboarded as a supplier and asks to be paid to its bank account.

In the model

Business Partner (carrier) → has → Identifier (register number)
Business Partner → has → Tax Registration (VAT)
Business Partner → has → Legal Form
Business Partner → has → Business Partner Status
Business Partner → holds → Account Holder Relationship → for → Bank Account → verified by → Account Verification

What CDQ checks

Check the register entry, VAT number, legal form and active status. Verify that the account belongs to the carrier before the first payment.

How the model handles it

Fits, entirely within Business Partner and Payment.

4Logistics

Ship-to points and an invoice address

A customer receives goods at three warehouses, each identified by a GLN at the dock. Invoices go to a PO box.

In the model

Business Partner (customer) → operates → Site (warehouse, GLN) → located at → Location → has → Address (physical)
Location → has → Geolocation
Business Partner → uses → Address (invoicing, PO box)

What CDQ checks

Check the GLNs, geocode the warehouses and validate the physical addresses. Validate the PO box as a postal address without a location.

How the model handles it

Fits. This is the case the split between Address and Site is made for: physical places through Site, the postal address directly.

5Retail

Listing a new article

A supplier introduces a product sold in each, case and pallet units.

In the model

Material (retail article) → represents → Product → packed as → Trade Item (each, case, pallet with GTINs)
Material → has → Product Partner Relationship (supplier, brand owner) → with → Business Partner

What CDQ checks

Check the GTINs and their GS1 registration. Check that the GTIN prefix is licensed to the stated brand owner.

How the model handles it

Fits, with one open point: the brand owner is a fact about the canonical product, not about the retailer's article (see above).

6Retail

Store network with franchisees

Stores under one banner are partly company-owned and partly run by franchisees.

In the model

Business Partner (brand) → brand of → Business Relationship → to → Business Partner (legal entity)
Business Partner (franchisee) → franchise of → Business Relationship → to → Business Partner (brand owner)
Business Partner (franchisee) → operates → Site (store) → located at → Location → has → Address

What CDQ checks

Check each franchisee in the register. Validate and geocode the store addresses. Keep the brand and franchise network consistent.

How the model handles it

Fits. Needs "brand of" and "franchise" as types of Business Relationship (see above).

7Chemistry

A new substance of very high concern

A substance is added to the REACH candidate list. Articles containing more than 0.1 % of it must be declared.

In the model

Product → has → Product Attribute (substance composition, CAS)
Material → represents → Product
Material → has → Product Partner Relationship (supplier) → with → Business Partner
Product → classified as → Product Classification (dangerous goods)

What CDQ checks

Recompute the affected products on each list update. Name the suppliers to ask for declarations.

How the model handles it

Fits. Substances stay attributes of the product. This case needs no separate substance entity.

8Chemistry

Environmental permit of a production plant

A plant needs a valid emission permit and an ISO 14001 certificate. The materials made there are at risk if either lapses.

In the model

Certificate (permit, ISO 14001) → has → Certificate Scope → covers → Site (plant)
Certificate → issued by → Issuer → is a → Business Partner (authority, certification body)
Material → has → Material Site Assignment → at → Site

What CDQ checks

Monitor validity and expiry. Check the issuer's accreditation. List the materials affected by a lapse.

How the model handles it

Fits. The site links certificate and product without a direct link from certificate to material.

9Pharma

Supplying a wholesaler

Before medicines are shipped, the customer's wholesale distribution authorisation and its storage site are checked.

In the model

Certificate (distribution authorisation) → has → Certificate Scope → covers → Business Partner (wholesaler)
Certificate → has → Certificate Scope → covers → Site (warehouse)
Business Partner → operates → Site
Certificate → issued by → Issuer → is a → Business Partner (authority)

What CDQ checks

Verify the authorisation against the authority's register. Monitor expiry. Block shipments to sites the authorisation does not cover.

How the model handles it

Fits. One certificate with two scopes covers the company and its site. No new entity is needed.

10Pharma

Qualifying a manufacturer of an active ingredient

An active pharmaceutical ingredient is sourced from a manufacturer abroad. A GMP certificate for the manufacturing site is required.

In the model

Material (API) → represents → Product → has → Product Identifier (CAS)
Material → has → Product Partner Relationship (manufacturer) → with → Business Partner → operates → Site
Certificate (GMP) → has → Certificate Scope → covers → Site
Product → originates in → Administrative Area (country)

What CDQ checks

Resolve the manufacturer. Verify the GMP certificate of exactly the site that makes the ingredient. Record the country of origin.

How the model handles it

Fits, and connects all five domains through Site.

Foundations

The model sits at the top of a three-level stack. The conceptual data model gives the business view of what the data means. RDOM is the logical model beneath it, the technical standard by which APIs, databases and indexes name and structure the data. The implementation level, called the physical level in the modelling literature, is how each service puts RDOM into practice. Each level realizes the one above it, so the business view can be documented and refined without changing RDOM or any system.

Level	What it describes	At CDQ	Changes when
Conceptual	What the data means in business terms: entity types, relationships and constraints, without technical structure	This model: domains, entities, attributes, relationships and value sets (Elements of the conceptual level)	CDQ's understanding of the business changes
Logical	How the data is structured, named and typed, independent of a particular database or interface	RDOM, the centrally managed OpenAPI schemas (Reference Domain Object Model)	A new service or field is standardized
Implementation	How each system actually stores, indexes and transmits the data	API payloads, databases, search indexes and stores inside each service, designed according to RDOM	Storage, performance or interface needs change

Elements of the conceptual level

On meta.cdq.com every element of the model is called a concept, in line with ISO/IEC 11179. On the conceptual level these concepts are of five kinds. RDOM realizes them as schema objects, fields and enumerations, and the implementations as tables, columns, index fields and payload properties.

Element	Meaning	Example	On meta.cdq.com
Domain	A family of entities with their own identity and reference data	Payment	Grouping of root concepts
Entity	Short for entity type: a kind of thing the business deals with, not a single occurrence. A single occurrence is a record, and matching, monitoring and sharing work on records. An entity that relates other entities and carries attributes of its own, such as Account Holder Relationship, is an associative entity.	Bank Account. One specific bank account is a record.	Root or node concept
Attribute	A property of an entity	IBAN	Leaf concept
Relationship	A typed link between entities, with cardinality	Bank Account is held at a Financial Institution	Relation
Value set	The allowed values of an attribute, the conceptual domain of ISO/IEC 11179	Account status: active, closed	Type concept

Where the levels come from

The idea of separate levels linked by mappings goes back to the three-schema architecture of the ANSI/X3/SPARC Study Group on Database Management Systems, formalised in ISO/TR 9007. Its middle level, the conceptual schema, was meant as the single description of the enterprise's data, but it mixed business meaning with technical structure. Kent proposed splitting it in two, a part that describes the enterprise and a part that describes the data structures. That split is the conceptual and logical level used in practice today. CDQ's setup follows it exactly: the conceptual data model is the business half, RDOM the logical half. RDOM's role across all services is also what integration architecture calls a canonical data model.

Why "conceptual data model"

In the standards the business-facing level is the conceptual schema. The research field calls the discipline conceptual modelling, with its own conference since 1979, today the International Conference on Conceptual Modeling. "Conceptual data model" is the established practitioner term for this level and the counterpart of "logical data model", the role RDOM plays, so the pair is self-explaining.

The alternatives carry baggage. "Data model" alone is ambiguous next to RDOM, which is a data model too. "Domain model" collides with Domain-Driven Design, where a domain means something else than a data domain. "Ontology" implies formal logic and reasoning the model does not claim. "Semantic model" is read today as a layer of business intelligence tools.

How the foundations shape the model

Foundation	What it means here
Entity-relationship notation	Entities, relationships and cardinalities in the diagrams follow Chen's entity-relationship model, the original notation for the conceptual level.
100 % principle	ISO/TR 9007 requires every relevant aspect of the universe of discourse in the conceptual schema. Here the universe of discourse is what CDQ services act on. Principle 1 decides what is relevant, and that is then modelled here and nowhere else.
Conceptualization principle	The conceptual level holds only conceptually relevant aspects, without data representation, physical organisation or access paths. Principles 6 and 10 apply it: SAP structures and RDOM field layouts never shape the business view.
Concepts and their realizations	ISO/IEC 11179 separates a data element concept (an object class with a property) from a data element (the concept with a representation). Concepts on meta.cdq.com are the former, and RDOM fields are the latter.

The same layering in practice

Standard	How it layers
ISO 20022, financial messaging	The standard's metamodel defines a conceptual, a logical and a physical level with traceability from one to the next. Business components are modelled once and realized in message definitions and syntaxes such as XML and JSON.
EU Core Vocabularies	Core Business, Core Person and Core Location are deliberately minimal conceptual models of a legal entity, a person and a location. Application profiles and technical representations are derived from them under the SEMIC style guide's separation of concerns.
UN/CEFACT core components	Syntax-neutral core components form the conceptual layer of B2B document standards such as UBL. Business information entities and XML bindings realize them in context, standardized as ISO 15000-5.

Not everyone shares one model. Domain-Driven Design holds that a model is consistent only within a bounded context and warns against enterprise-wide canonical models. CDQ's setup is compatible with that critique: RDOM is canonical within one bounded context, CDQ's own services, and principle 1 keeps the conceptual model to what those services act on. OMG's Model Driven Architecture names the same three levels differently, as computation-independent, platform-independent and platform-specific model.