Data Modeling Tutorial: ShaDey Inc. | CDM, LDM, PDM for AI/ML Pipelines

1 Introduction

This tutorial teaches the difference between Conceptual, Logical, and Physical data models through a realistic case study. You will follow ShaDey Inc. as it builds data products for AI/ML, and see how governance (or the lack of it) at the modeling stage determines whether those products succeed or fail.

1. What CDM, LDM, and PDM mean and how they relate.
2. How three different governance approaches produce radically different models.
3. How modeling quality propagates into feature stores, training data, and ML model performance.
4. What a data operating model looks like at each governance maturity level.

This page is a companion to the Data Governance Scenarios visualization. The three scenarios referenced here (Ideal (Governed), Scenario 1 (Without Business Owners), and Scenario 2 (No Governance)) are defined in full on that page.

2 ShaDey Inc.: Business Context

ShaDey Inc. is a mid-size omnichannel retailer ($500M revenue, 120 physical stores, e-commerce platform) selling consumer goods. The data team has been tasked with building governed data products that will power AI/ML pipelines for personalization, forecasting, and operational optimization.

Core Data Entities

Six business entities form the backbone of ShaDey Inc.'s data landscape. Every data product draws from one or more of these.

Customer Product Order Store Inventory Supplier

Target AI/ML Data Products

ShaDey Inc. aims to produce seven governed data products. Each has a domain owner, defined consumers, and SLAs.

Customer 360

Unified customer profile combining demographics, loyalty, channel preference, and lifetime value. Feeds churn prediction and segmentation models.

Domain: Customer Management | Owner: VP Customer Ops

Product Catalog

Enriched product master with categories, attributes, pricing tiers, and supplier links. Feeds recommendation engine and assortment planning.

Domain: Merchandising | Owner: VP Merchandising

Sales Transactions

Governed sales data with order lines, returns, channels, and payments. Feeds revenue analytics and customer behavior models.

Domain: Sales & Revenue | Owner: Head of Sales Ops

Inventory Positions

Real-time stock levels by product and location. Feeds demand forecasting and stockout prediction.

Domain: Supply Chain | Owner: VP Supply Chain

Supplier Scorecard

Supplier performance metrics: lead times, defect rates, fill rates, contract compliance. Feeds supplier risk scoring and cost optimization.

Domain: Procurement | Owner: VP Procurement

Store Analytics

Store-level traffic, conversion, basket size, and labor utilization. Feeds store clustering and operational optimization.

Domain: Store Operations | Owner: VP Retail Ops

ML Feature Store

Pre-computed, governed features from all six domains. Serves as the AI/ML training and inference consumption layer with versioning, lineage, and data contracts.

Domain: Data & Analytics | Owner: Head of Data Science

A data product is not a table or a dashboard: it is a curated, governed, reusable dataset with a defined owner, documented schema, quality SLAs, and access controls. The quality of data products is determined by the quality of the data models underneath them.

3 What Are CDM, LDM, and PDM?

Data modeling progresses through three layers, each adding more detail. Think of it as moving from business language to structured specification to physical implementation.

Conceptual Data Model

CDM

Purpose: Define what the business cares about (entities, relationships, and domain boundaries) in business language.
Audience: Business Owners, Data Owners, CDO, Compliance, Data Architects
Key Artifacts: Entity definitions, glossary terms, ontology (IS-A, HAS-A, PART-OF), taxonomy, domain map, RACI matrix
Technology: None: completely technology-agnostic
Answers: "What are the things we need to know about, and how do they relate?"

Logical Data Model

LDM

Purpose: Define what attributes each entity has, their data types, constraints, business rules, and valid values, independent of any database.
Audience: Data Owners, Data Architects, Data Modelers, Data Stewards
Key Artifacts: Attribute definitions, data types, constraints, business rules, quality rules, normalization (3NF), reference data lists
Technology: Database-agnostic: no specific vendor or engine
Answers: "What do we need to know about each thing, and what rules govern that data?"

Physical Data Model

PDM

Purpose: Define how data is physically stored: table names, column types, indexes, partitions, and performance optimization.
Audience: Data Architects, Data Engineers, Data Modelers, DBAs
Key Artifacts: DDL (CREATE TABLE), naming conventions, indexes, partitions, SCD strategies, surrogate keys, storage optimization
Technology: Specific to target platform (Snowflake, Databricks, BigQuery, etc.)
Answers: "How do we implement this for performance, scalability, and governed access?"

Each layer builds on the previous one. The CDM ensures everyone agrees on what the data means. The LDM ensures the rules are correct. The PDM ensures the implementation is performant and governed. Skipping a layer means inheriting ambiguity downstream.

4 The Three Governance Scenarios

We will trace ShaDey Inc.'s data entities through CDM → LDM → PDM → Pipeline under three different governance approaches. Each scenario produces radically different data models and downstream outcomes.

Ideal: Governed Process

All stakeholders collaborate at every layer. Business meaning flows from concept to pipeline with full metadata, ontology, and quality governance.

Participants

Business Owners define entity meaning
Data Owners validate rules and quality
Data Architects design the model
CDO approves domain structure
Compliance reviews PII and regulatory scope

Governance Score: 95%

Scenario 1: Models Without Business

Data Architects and Modelers build the CDM and LDM in isolation. Business glossary terms are assumed, not validated. Engineering implements from a flawed blueprint.

Who Is Missing

Business Owners: no entity validation
Data Owners: no rule sign-off
CDO: no domain approval
Compliance: no PII review

Governance Score: 40%

Scenario 2: No Governance

Data Engineering builds pipelines and physical tables directly from source systems. No CDM, no LDM, no business glossary, no ontology, no metadata, no data contracts.

What Is Skipped

Entire Conceptual layer: skipped
Entire Logical layer: skipped
Business glossary: does not exist
Data contracts: does not exist

Governance Score: 10%

5 Ideal Scenario: Full Walkthrough

Governed Data Modeling

All stakeholders collaborate. Business meaning flows from concept through implementation. Every entity has a glossary definition, ontology relationships, validated attributes, quality rules, and lineage to the physical layer.

Step 1: Conceptual Data Model

Business Owners, Data Owners, and Data Architects define what matters. Every entity has a glossary definition, domain owner, and ontology relationships.

Customer

Definition: "A person or organization that has purchased from or registered with ShaDey Inc. through any channel."
B2C B2B Wholesale
Domain: Customer Management | Owner: VP, Customer Operations

places 1..*

Order

Definition: "A purchase transaction recording items bought, channel, and payment, the core revenue event."
POS E-Commerce B2B
Domain: Sales & Revenue | Owner: Head of Sales Operations

contains 1..*

Product

Definition: "A sellable item in ShaDey Inc.'s portfolio, identified by a unique SKU, belonging to a Category within a Department."
Ontology: Product IS-A MaterialItem; Product BELONGS-TO Category; Product HAS-MANY Variants
Domain: Merchandising | Owner: VP, Merchandising

sold at 1..*

Store

Definition: "A physical retail location or digital channel where ShaDey Inc. sells products to customers."
Ontology: Store PART-OF Region; Region PART-OF Territory
Domain: Store Operations | Owner: VP, Retail Operations

tracks stock

Inventory

Definition: "The current quantity of a Product available at a Store, measured in sellable units."
Domain: Supply Chain | Owner: VP, Supply Chain

supplied by 1..*

Supplier

Definition: "An external organization that manufactures, distributes, or imports products sold by ShaDey Inc."
Ontology: Supplier PROVIDES Product; Supplier HAS-A Contract
Domain: Procurement | Owner: VP, Procurement

Governance artifacts at the CDM layer

Business glossary with 6 entity definitions approved by domain owners
Ontology relationships documented (IS-A, HAS-A, BELONGS-TO, PART-OF, PROVIDES)
Taxonomy: Sales, Supply Chain, Finance, Customer, Merchandising, Procurement domains classified
RACI matrix signed off by CDO
PII scope identified (Customer entity: name, email, address)
Regulatory scope: GDPR for EU customers, SOX for financial reporting
Naming convention: full English words, PascalCase (Customer, SalesOrder, StoreLocation)

Step 2: Logical Data Model

Data Owners and Data Modelers define every attribute with business definitions, data types, constraints, valid values, and quality rules. We show Customer and Supplier in detail.

Entity: Customer

Attribute	Type	Constraint	Glossary / Business Rule
`customer_id`	UUID	PK, NOT NULL	Globally unique identifier, system-generated
`full_name`	VARCHAR(200)	NOT NULL	PII: requires masking in non-prod environments
`email`	VARCHAR(255)	UNIQUE, NOT NULL	PII: consent required for marketing use (GDPR Art. 6)
`customer_type`	ENUM	NOT NULL, DEFAULT 'B2C'	B2C \| B2B \| Wholesale: determines pricing tier and payment terms
`loyalty_tier`	ENUM	NULLABLE	Bronze \| Silver \| Gold \| Platinum: recalculated monthly from trailing 12-month spend
`registration_date`	DATE	NOT NULL	Date of first purchase or explicit account creation
`preferred_channel`	ENUM	NULLABLE	Store \| Online \| App: derived from behavioral analysis
`ltv_segment`	ENUM	NULLABLE	High \| Medium \| Low: output of LTV model, refreshed quarterly
`primary_store_id`	UUID	FK → Store	Most-frequented physical store (from transaction history)

Business Rules (Customer)

customer_type determines pricing tier and payment terms
loyalty_tier recalculated monthly from trailing 12-month spend
email must be unique across all customer types
Customers inactive >24 months flagged for GDPR right-to-erasure review

Entity: Supplier

Attribute	Type	Constraint	Glossary / Business Rule
`supplier_id`	UUID	PK, NOT NULL	Globally unique identifier
`supplier_name`	VARCHAR(200)	NOT NULL	Legal entity name as registered
`supplier_type`	ENUM	NOT NULL	Manufacturer \| Distributor \| Importer: determines lead time expectations
`country_code`	CHAR(3)	NOT NULL	ISO 3166-1 alpha-3: used for trade compliance
`lead_time_days`	INTEGER	NOT NULL	Average calendar days from PO to delivery at warehouse
`quality_rating`	DECIMAL(3,2)	CHECK 0.00–5.00	Rolling 12-month rating based on defect rate, fill rate, on-time delivery
`contract_start_date`	DATE	NOT NULL	Effective date of current master agreement
`payment_terms`	VARCHAR(20)	NOT NULL	Net30 \| Net60 \| Net90: from procurement agreement
`is_certified`	BOOLEAN	DEFAULT FALSE	TRUE if supplier passed ShaDey Inc. quality audit in last 12 months
`primary_category_id`	UUID	FK → ProductCategory	Primary product category this supplier provides

Quality Rules (Supplier)

quality_rating completeness ≥ 99%, accuracy validated quarterly
country_code validity = 100% against ISO reference data
is_certified must be refreshed annually; expired certifications auto-set to FALSE
Duplicate detection on supplier_name + country_code

Order, Product, Store, Inventory attributes (click to expand)

Entity: Order

Attribute	Type	Constraint	Note
`order_id`	UUID	PK	Unique per transaction
`customer_id`	UUID	FK → Customer	Who purchased
`store_id`	UUID	FK → Store	Where purchased
`order_date`	TIMESTAMP	NOT NULL	Transaction timestamp (UTC)
`channel`	ENUM	NOT NULL	POS \| Web \| App \| Phone
`total_amount`	DECIMAL(12,2)	NOT NULL	After discounts, before tax
`currency`	CHAR(3)	DEFAULT 'USD'	ISO 4217
`status`	ENUM	NOT NULL	Placed \| Shipped \| Delivered \| Returned

Entity: Product

Attribute	Type	Constraint	Note
`product_id`	UUID	PK	System-generated
`sku`	VARCHAR(30)	UNIQUE, NOT NULL	Stock-keeping unit
`product_name`	VARCHAR(200)	NOT NULL	Marketing name
`category`	VARCHAR(100)	NOT NULL	From product hierarchy
`department`	VARCHAR(100)	NOT NULL	Top-level grouping
`unit_cost`	DECIMAL(10,2)	NOT NULL	Landed cost from supplier
`unit_price`	DECIMAL(10,2)	NOT NULL	Retail selling price
`primary_supplier_id`	UUID	FK → Supplier	Primary supply source

Entity: Store

Attribute	Type	Constraint	Note
`store_id`	UUID	PK	System-generated
`store_name`	VARCHAR(100)	NOT NULL	Display name
`store_type`	ENUM	NOT NULL	Physical \| E-Commerce \| Pop-Up
`region`	VARCHAR(50)	NOT NULL	Geographic region
`territory`	VARCHAR(50)	NOT NULL	Sales territory
`open_date`	DATE	NOT NULL	Date store opened

Entity: Inventory

Attribute	Type	Constraint	Note
`inventory_id`	UUID	PK	Composite natural key: product + store + date
`product_id`	UUID	FK → Product	Which product
`store_id`	UUID	FK → Store	Which location
`quantity_on_hand`	INTEGER	NOT NULL, ≥ 0	Current sellable units
`quantity_on_order`	INTEGER	DEFAULT 0	Units in transit from supplier
`snapshot_date`	DATE	NOT NULL	Date of stock count

Step 3: Physical Data Model

Dimensional model (star schema) with consistent naming, SCD Type 2 for slowly changing dimensions, governed naming conventions, and full lineage to the LDM.

dim_customer (SCD Type 2)

CREATE TABLE dim_customer ( customer_sk BIGINT IDENTITY PRIMARY KEY, customer_id UUID NOT NULL, -- natural key from LDM full_name VARCHAR(200) NOT NULL, email VARCHAR(255), -- PII: masked in non-prod customer_type VARCHAR(20) NOT NULL, -- B2C | B2B | Wholesale loyalty_tier VARCHAR(20), registration_date DATE NOT NULL, preferred_channel VARCHAR(20), ltv_segment VARCHAR(10), primary_store_sk BIGINT REFERENCES dim_store, is_current BOOLEAN DEFAULT TRUE, effective_from TIMESTAMP NOT NULL, effective_to TIMESTAMP, _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Partitioned by registration_date (year) | Clustered on customer_id -- Lineage: LDM.Customer → CDM.Customer glossary term

dim_supplier

CREATE TABLE dim_supplier ( supplier_sk BIGINT IDENTITY PRIMARY KEY, supplier_id UUID NOT NULL, supplier_name VARCHAR(200) NOT NULL, supplier_type VARCHAR(30) NOT NULL, country_code CHAR(3) NOT NULL, lead_time_days INT NOT NULL, quality_rating DECIMAL(3,2), payment_terms VARCHAR(20) NOT NULL, is_certified BOOLEAN DEFAULT FALSE, primary_category_sk BIGINT REFERENCES dim_product_category, is_current BOOLEAN DEFAULT TRUE, effective_from TIMESTAMP NOT NULL, effective_to TIMESTAMP, _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- SCD Type 2 on quality_rating, is_certified, payment_terms -- Lineage: LDM.Supplier → CDM.Supplier glossary term

fact_order, dim_product, dim_store, fact_inventory DDL (click to expand)

fact_order

CREATE TABLE fact_order ( order_sk BIGINT IDENTITY PRIMARY KEY, order_id UUID NOT NULL UNIQUE, customer_sk BIGINT NOT NULL REFERENCES dim_customer, product_sk BIGINT NOT NULL REFERENCES dim_product, store_sk BIGINT NOT NULL REFERENCES dim_store, order_date_sk INT NOT NULL REFERENCES dim_date, channel_code VARCHAR(10) NOT NULL, quantity DECIMAL(10,3) NOT NULL, unit_price DECIMAL(10,2) NOT NULL, discount_amount DECIMAL(10,2) DEFAULT 0, line_total DECIMAL(12,2) NOT NULL, currency_code CHAR(3) DEFAULT 'USD', _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Grain: one row per order line item -- Partitioned by order_date_sk (monthly)

dim_product

CREATE TABLE dim_product ( product_sk BIGINT IDENTITY PRIMARY KEY, product_id UUID NOT NULL, sku VARCHAR(30) NOT NULL, product_name VARCHAR(200) NOT NULL, category VARCHAR(100) NOT NULL, department VARCHAR(100) NOT NULL, unit_cost DECIMAL(10,2), unit_price DECIMAL(10,2), primary_supplier_sk BIGINT REFERENCES dim_supplier, is_current BOOLEAN DEFAULT TRUE, effective_from TIMESTAMP NOT NULL, effective_to TIMESTAMP, _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

dim_store

CREATE TABLE dim_store ( store_sk BIGINT IDENTITY PRIMARY KEY, store_id UUID NOT NULL, store_name VARCHAR(100) NOT NULL, store_type VARCHAR(20) NOT NULL, region VARCHAR(50) NOT NULL, territory VARCHAR(50) NOT NULL, open_date DATE NOT NULL, is_current BOOLEAN DEFAULT TRUE, effective_from TIMESTAMP NOT NULL, effective_to TIMESTAMP, _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

fact_inventory_snapshot

CREATE TABLE fact_inventory_snapshot ( product_sk BIGINT NOT NULL REFERENCES dim_product, store_sk BIGINT NOT NULL REFERENCES dim_store, snapshot_date_sk INT NOT NULL REFERENCES dim_date, quantity_on_hand INT NOT NULL, quantity_on_order INT DEFAULT 0, _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (product_sk, store_sk, snapshot_date_sk) ); -- Grain: one row per product per store per day -- Partitioned by snapshot_date_sk (monthly)

Naming Convention Standard

dim_ prefix for dimensions, fact_ for fact tables, ref_ for reference data, stg_ for staging
_sk suffix for surrogate keys, _id for natural keys, _code for coded values
Snake_case, full words, no abbreviations

Step 4: Data Pipelines & Operating Model

Pipelines implement ETL with full lineage, quality gates, and formal data contracts.

Access Control

Role-based access: Analyst, Engineer, Steward, Admin
Column-level masking on PII fields
Row-level security by region/territory
Audit log for all data access

Metadata & Lineage

Column-level lineage: source → staging → dim/fact
Business glossary linked to every column
Impact analysis for schema changes
Automated data catalog (e.g., DataHub, Collibra)

Data Contracts

Schema version, SLA (freshness ≤ 15 min)
Quality thresholds (null rate < 0.1%)
Owner, consumers, breaking-change policy
Automated enforcement via CI/CD

With full governance, ShaDey Inc. has 6 entities with glossary definitions, 50+ attributes with validated business rules, a star schema with SCD Type 2, data contracts on every pipeline, and complete lineage from business concept to physical column. This is the foundation for trustworthy AI/ML.

6 Scenario 1: Models Without Business Owners

CDM & LDM Built in Isolation

Data Architects and Modelers build the CDM and LDM without Business Owners, Data Owners, or Compliance. The glossary is assumed from source system documentation. Engineering implements from an unvalidated blueprint.

Step 1: Conceptual Data Model (Degraded)

Entities are named after source system objects (SAP tables) rather than business concepts. No glossary validation, no ontology sign-off.

Cust

Definition: "An account record in the ERP system."
No distinction between B2C/B2B/Wholesale. No glossary. No domain owner assigned.
Ontology: Cust HAS-A AccountNumber (technical, not business relationship)

links to

SalesDoc

Definition: "A sales document header from SAP VBAK."
Named after source table. Includes orders, returns, and credit memos in a single entity (no business distinction).

references

Material

Definition: "A record in MARA table."
Called "Material" (SAP term) instead of "Product" (business term). Missing: Category hierarchy, Variant concept, Department.

stored in

Plant

Definition: "An SAP Plant (WERKS)."
"Plant" is an SAP concept, not how the business thinks about stores. E-commerce not represented.

Entity names mirror source system, not business language
"Order" mixed with returns and credit memos in "SalesDoc"
"Inventory" entity missing entirely, assumed to be a Plant attribute
"Supplier" entity missing, treated as a field on Material
No glossary, no ontology validation, no domain ownership, no PII identification

Step 2: Logical Data Model (Degraded)

Attributes defined from data profiling only. No business validation. Abbreviated names, missing attributes, guessed business rules.

Entity: Cust

Attribute	Type	Constraint	Problem
`cust_id`	INT	PK	INT not UUID: tied to source system sequence
`nm`	VARCHAR(50)	–	Truncated name, nullable, not flagged PII
`email`	VARCHAR(100)	–	Not flagged PII, not unique, nullable
`tp`	VARCHAR(10)	–	No valid values defined. Contains "1","2","3"
`reg_dt`	DATE	–	Abbreviated name, inconsistent convention

Missing: loyalty_tier, preferred_channel, ltv_segment, primary_store_id
tp contains "1","2","3": engineers guess these mean customer types (they're actually status codes)
No business rules documented: pricing tier logic unknown
No quality rules: 15% of email values are NULL

Supplier LDM in Scenario 1 (click to expand)

Supplier is not modeled as a separate entity. Instead, a vendor_no field exists on the Material entity:

Attribute	Type	Problem
`vendor_no`	VARCHAR(10)	SAP vendor number, no link to supplier master. Cannot track lead time, quality, or contracts.
`vendor_nm`	VARCHAR(50)	Denormalized on Material. If vendor changes name, must update every product.

No supplier entity: cannot build Supplier Scorecard data product
No quality rating, lead time, or certification tracking
No supplier-to-product relationship model

Step 3: Physical Data Model (Flawed)

Tables built on the flawed LDM. No star schema, no SCD, no surrogate keys.

tbl_customer (no SCD)

CREATE TABLE tbl_customer ( cust_id INT PRIMARY KEY, -- source system ID nm VARCHAR(50), -- truncated email VARCHAR(100), -- not PII-flagged tp VARCHAR(10), -- "1","2","3" ?? reg_dt DATE ); -- No SCD tracking | No partitioning | No lineage to logical model

tbl_sales (flat denormalized)

CREATE TABLE tbl_sales ( doc_id INT PRIMARY KEY, cust_id INT, material VARCHAR(18), -- SAP MATNR raw plant VARCHAR(4), -- SAP WERKS raw doc_dt DATE, -- no timestamp amt FLOAT, -- rounding risk! doc_type VARCHAR(4) -- mixes orders + returns ); -- No surrogate keys, no dim references, no grain definition

Step 4: Operating Model (Degraded)

Access Control

Database-level grants only (no column masking)
PII not identified: no masking rules
No audit trail for data access

Metadata & Lineage

Partial lineage (tool-generated, not validated)
No business glossary linked to columns
Schema changes documented informally in wiki

Data Contracts

Informal contracts: schema only, no SLA
No quality thresholds enforced
Consumers discover breaking changes after deployment

Without business validation, the CDM uses source-system names ("Cust", "Material", "Plant"), the LDM has 5 attributes instead of 9, business rules are guessed, PII is unidentified, and the Supplier entity doesn't exist. Every downstream data product inherits these gaps.

7 Scenario 2: No Governance

Pipelines Built Without Any Data Model

Data Engineering builds pipelines and physical tables directly from source extracts. No CDM, no LDM, no business glossary. Each engineer creates ad-hoc tables per JIRA ticket.

Step 1: Conceptual Data Model

No Conceptual Data Model exists.
There is no shared definition of what "Customer", "Product", or "Supplier" means at ShaDey Inc. Each team and pipeline defines these concepts independently.

Step 2: Logical Data Model

No Logical Data Model exists.
No shared attribute definitions, no data types, no business rules, no quality rules. Engineers infer structure from source system exports and Slack conversations.

Step 3: Physical Data Model (Chaotic)

Ad-hoc tables created per JIRA ticket by different engineers. No naming convention, no design, no documentation.

Engineer A (JIRA-1234)

CREATE TABLE customers ( id INT, name TEXT, type TEXT, created DATE );

Engineer B (JIRA-5678)

CREATE TABLE cust_data_v2 ( customer_id VARCHAR(50), full_name VARCHAR(200), cust_type INT, email VARCHAR(100), signup_dt TIMESTAMP );

Engineer C (ad-hoc Slack request)

CREATE TABLE customer_export_final_FINAL ( cid TEXT, nm TEXT, tp TEXT, e TEXT ); -- "temporary" table from 8 months ago -- 3 pipelines now depend on it -- nobody knows who created it or why

3 "customer" tables: different schemas, different IDs, different row counts (1.2M / 890K / 1.4M)
No surrogate keys, no foreign keys, no referential integrity
No naming convention: _v2, _final_FINAL, single-letter columns
Supplier data: a CSV file on a shared drive, loaded manually once a quarter
ML teams pick whichever table "looks right," and different models use different tables

Step 4: Operating Model (Absent)

Access Control

Shared service account for all pipelines
PII flowing unmasked into ML training sets
No audit log: GDPR violation risk

Metadata & Lineage

No lineage: nobody knows where data comes from
No catalog: discovery via Slack questions
"Ask Priya, she might know that table"

Data Contracts

No contracts: schema changes break downstream
No SLAs: pipelines fail silently
No versioning: tables overwritten in place

Without any governance, there is no shared understanding of what data means. Three engineers create three different "customer" tables. There is no CDM, no LDM, no naming convention, no data contracts. The Supplier data product is impossible (the data lives in a CSV). Every AI/ML pipeline is an archaeology exercise.

8 Cross-Scenario Comparison

Side-by-side comparison across every dimension of the data modeling process.

Dimension	Ideal: Governed	Scenario 1: Without Business	Scenario 2: No Governance
CDM Entities	6 entities with glossary definitions, ontology, domain ownership, PII classification Complete	4 entities named after source system (Cust, SalesDoc, Material, Plant). No glossary Degraded	Does not exist Missing
LDM Attributes	9 Customer attrs, 10 Supplier attrs. Full types, constraints, valid values, business rules, quality rules Complete	5 Customer attrs with abbreviations. No constraints, no business rules. Supplier = 2 fields on Material Incomplete	Does not exist Missing
PDM Design	Star schema: `dim_`/`fact_`. SCD2, surrogate keys, partitioned, naming convention, lineage Governed	Flat tables: `tbl_customer`, `tbl_sales`. No SCD, FLOAT for money, mixed doc types Flawed	3 conflicting customer tables, no design, no convention Chaotic
Master / Reference Data	Centrally managed reference tables (currency, country, product category). Single source of truth Managed	Hard-coded in pipelines. "1","2","3" for customer type with no reference lookup Ad-hoc	Each pipeline has its own enums. Inconsistent across teams Absent
Naming Convention	`dim_customer`, `fact_order`, `customer_type`, `order_date`	`tbl_customer`, `tbl_sales`, `tp`, `nm`, `amt`	`customers`, `cust_data_v2`, `customer_export_final_FINAL`
Access Control	Role-based, column-level PII masking, row-level security, audit log Controlled	Database-level grants only, no PII masking Partial	Shared service account, PII in ML training sets unmasked None
Metadata & Lineage	Full column-level lineage, business glossary linked, automated catalog Complete	Partial lineage (tool-generated), no glossary link, wiki docs Partial	No lineage, no catalog, discovery via Slack None
Data Contracts	Schema + SLA + quality thresholds + versioning on every pipeline output Enforced	Informal wiki page with schema only, no SLA, no quality gates Informal	No contracts. Schema changes break consumers silently None
PII Handling	Tagged at CDM, masked in non-prod, consent tracked Compliant	Not identified at modeling stage. Discovered during audit Risky	PII flowing into ML training sets unmasked Non-compliant
Supplier Data Product	Full `dim_supplier` with 10 attributes, quality rating, certification, lead time Available	2 vendor fields on Material entity. Cannot build Supplier Scorecard Impossible	CSV on shared drive. Manual quarterly load Absent
Time to New Feature	1–2 days (documented sources, clear lineage)	1–2 weeks (reverse-engineer meaning, validate assumptions)	3–6 weeks (archaeology: find table, guess schema, ask around)

9 AI/ML Implications

How does data modeling quality propagate through the feature store and into ML model performance? We trace the Customer Churn Prediction model and the Supplier Risk Scoring model across all three scenarios.

Model 1: Customer Churn Prediction

Predict which customers will stop purchasing within 90 days. Requires: demographics, RFM (recency/frequency/monetary), loyalty, channel, and store affinity features.

Ideal: Governed

dim_customer
fact_order

Feature
Engineering

Feature
Store

Churn
Model

customer_purchase_recency_days

Source fact_order.order_date

Logic DATEDIFF(days, MAX(order_date), CURRENT_DATE) per customer

SLA Refreshed daily, null rate < 0.1%

customer_loyalty_tier

Source dim_customer.loyalty_tier (SCD2 current)

Logic Ordinal: Bronze=0, Silver=1, Gold=2, Platinum=3

92%AUC-ROC

87%Precision @ 10%

94%Feature Completeness

Trusted by business. Saves $2.1M/year.

Scenario 1: Without Business

tbl_customer
tbl_sales

Guesswork
Engineering

Ad-hoc
Features

Churn
Model

cust_recency

Source tbl_sales.doc_dt (DATE, not TIMESTAMP)

Problem Returns counted as "activity," inflating false negatives

cust_type_flag

Problem ML engineer guesses tp="1" → B2C. Actually "1"=Active. Entire feature is meaningless.

74%AUC-ROC

61%Precision @ 10%

58%Feature Completeness

$800K wasted on mis-targeted offers.

Scenario 2: No Governance

customers?
cust_data_v2?

Archaeology
Exercise

Unreliable
Features

Untrusted
Model

recency (version depends on engineer)

Problem Two models compute "recency" differently. Predictions conflict.

customer_count (contradictory)

Problem Table 1: 1.2M rows. Table 2: 890K. Table 3: 1.4M. Which is truth?

61%AUC-ROC

43%Precision @ 10%

31%Feature Completeness

$1.5M spent building a model nobody uses.

Model 2: Supplier Risk Scoring

Score suppliers by risk of disruption based on lead time variance, defect rate, fill rate, and certification status.

Ideal

supplier_lead_time_variance

Source dim_supplier.lead_time_days + PO history

Logic STDDEV of actual vs. promised lead time (rolling 6 mo)

supplier_quality_rating

Source dim_supplier.quality_rating

Logic Direct mapping, validated quarterly

89%AUC-ROC: Supplier Risk

Procurement trusts the model. Proactive supplier switches save $1.2M/year in disruption costs.

Scenario 1

Cannot build this model.
Supplier is not a separate entity. Only vendor_no and vendor_nm exist on the Material record. No lead time, quality rating, or certification data available.

Model: Not Possible

Procurement relies on spreadsheets and gut feel. Supply disruptions cost $3M/year.

Scenario 2

Supplier data is a CSV file.
Updated manually once a quarter. Contains vendor names and phone numbers. No structured data for ML consumption.

Model: Not Possible

No one even knows this model could exist. The business case has never been articulated.

ML Feature Store: Training Consumption Layer

The ML Feature Store is the AI/ML training consumption layer, a governed, versioned repository of pre-computed features that all models draw from.

Ideal: Governed Feature Store

Every feature has: name, description, source lineage, owner, SLA
Features are versioned (v1, v2) with deprecation policy
Data contracts: freshness ≤ 24h, null rate < 0.1%
PII features are masked or excluded from training sets
Single source of truth: all models share the same features
Point-in-time correctness: no data leakage in training sets

Scenario 1: Ad-hoc Features

Features undocumented: logic in notebooks
No versioning: feature logic changes silently
No SLAs: stale features go unnoticed
PII not identified in feature pipelines
Feature duplication: 3 teams compute "recency" differently

Scenario 2: No Feature Store

No feature store exists
Each model computes features from scratch
Features embedded in training notebooks (not reusable)
PII in training data: regulatory violation
No point-in-time correctness: data leakage endemic
Model reproducibility: impossible

ML models are only as good as the data they are trained on. But data quality isn't just about clean values; it's about semantic correctness. A feature derived from a column whose business meaning is misunderstood is worse than a missing feature, because it introduces systematic bias that's invisible to both the model and the data scientist. Garbage semantics in, garbage predictions out.

10 Key Lessons

The core message of this tutorial in five principles.

Fixing a misunderstood entity at the CDM costs 1 meeting. At the LDM: a model redesign. At the PDM: a data migration. After the ML model is in production: trust, and trust, once lost, is the most expensive thing to rebuild.

Calling an entity "Material" instead of "Product" or "Plant" instead of "Store" encodes a source-system worldview into every downstream pipeline. Names determine how engineers think about the data.

Without a Supplier entity in the CDM, the entire Supplier Scorecard data product is impossible. Without an Inventory entity, demand forecasting is crippled. Governance gaps at the modeling layer don't degrade AI/ML; they prevent it.

The fact that loyalty_tier is recalculated monthly from trailing 12-month spend is not a business detail; it's the strongest predictor of churn. When business rules are undocumented (Scenario 1) or nonexistent (Scenario 2), the most valuable features cannot be engineered.

In Scenario 2, each ML project spends 3–6 weeks on data archaeology before any modeling begins. The Ideal scenario invests upfront in CDM/LDM/PDM and recoups that investment in every subsequent project, delivering features in 1–2 days instead of weeks.

Metric	Ideal	Scenario 1	Scenario 2
Churn Model AUC	92%	74%	61%
Supplier Risk Model	89% AUC	Not Possible	Not Possible
Data Products Possible	7 of 7	4 of 7	1 of 7 (degraded)
Feature Engineering Time	1–2 days	1–2 weeks	3–6 weeks
Annual Cost Impact	Saves $3.3M	Wastes $3.8M	Wastes $4.5M+
Governance Score	95%	40%	10%

For the companion visualization of these three governance scenarios with detailed stakeholder analysis, quality dimensions, certification gates, and remediation roadmaps, see Data Governance Scenarios. For the full product lifecycle from market need through continuous improvement, see the Product Lifecycle Journey.