Common Data Standard Reference Guide

Ensuring Structured, Reusable, and Scalable Data Architecture

1️⃣ Purpose of the Common Data Standard

The Common Data Standard (CDS) establishes a structured framework for defining DataMart views in a consistent and scalable manner. This standard:

✅ Promotes reusability across different datasets.
✅ Ensures alignment between business logic and reporting needs.
✅ Enables efficient data joins and minimises redundancy.
✅ Supports data governance and quality control.


2️⃣ Meta-Structured Views

The CDS model follows a consistent naming convention, ensuring interoperability across datasets.

View TypePurposeExample Views
Core (.core)Unique identifiers and key attributes.project.core, employee.core
Codes (.codes)Standard reference codes and classifications.project.codes, customer.codes
Details (.details)Additional attributes extending core data.project.details, employee.details
Value (.value)Financial or metric-based attributes.project.value, order.value
Status (.status)Tracks the current and past state of an entity.project.status, employee.status
History (.history)Tracks changes and historical values.project.history, customer.history

3️⃣ Naming Convention Guidelines

To maintain consistency across views, all DataMart structures follow a clear and predictable naming convention.

📌 Format:
<Datamart>.<ViewName>

ComponentDescriptionExample
DataMartThe subject of the dataset.project, employee, customer
ViewNameThe type of data view..core, .codes, .details

📌 Example Views Using Naming Conventions:

  • project.core → Contains essential identifiers (Project ID, Name, Status).
  • project.codes → Stores classification codes (Cost Centre, Business Type).
  • project.value → Holds financial metrics (Total Cost, Revenue).
  • project.status → Monitors project states (Active, Completed).
  • project.history → Retains historical records (Previous Status, Manager Changes).

🔹 Benefits of Standardised Naming:

Improves Discoverability – Easier for analysts and engineers to locate relevant data.
Enhances Data Governance – Reduces ambiguity in schema definitions.
Facilitates Query Optimisation – Simplifies SQL joins across structured datasets.

4️⃣ First Common Data Standard Views

Core Details (.core)

Core attributes that uniquely define each entity, providing fundamental identifying details.

Standardised Naming Convention: <entity>.core
Ensures Reusability Across Systems
Immutable Identifiers with Core Metadata

Entry CodeDescription
project.coreProject ID, Name, Type, Business Unit
employee.coreEmployee ID, Name, Job Title, Department

Dates & Timestamps (.dates)

🔹 Definition: All key date fields relevant to an entity, including start, end, and status update timestamps.
🔹 Examples:

Entry CodeDescription
project.datesStart Date, End Date, Estimated Completion Date, Milestone Dates
employee.datesHire Date, Probation End Date, Promotion Dates

Extended Attributes (.details)

Definition:
Additional attributes that extend the core entity’s information but are not required for identification.

Standardised Naming Convention: <entity>.details
Enriches Core Data with Additional Context
Allows Flexible Schema Expansion Without Impacting .core

Entry CodeDescription
project.detailsProject Start Date, End Date, Budget, Risk Level
employee.detailsEmployment Type, Contract Status, Benefits Tier
customer.detailsPreferred Contact Method, Account Manager
order.detailsFulfilment Status, Expected Delivery Date, Carrier

Financial Values & Measures (.values)

Quantitative or financial attributes related to the entity, supporting monetary, volume, or percentage-based analytics.

Standardised Naming Convention: <entity>.value
Financial & Metric-Based Representation
Optimised for Aggregation & Reporting

Entry CodeDescription
project.valuesProject Budget, Actual Spend, Variance, Forecasted Cost
employee.valuesSalary, Bonus, Hours Worked, Utilisation Rate

Standard Codes & Identifiers (.codes)

Stores reference codes, classifications, and standard identifiers used across multiple datasets to maintain consistency.

Standardised Naming Convention: <entity>.codes
Predefined Lookups for Normalisation
Enhances Data Quality & Consistency

Entry CodeDescription
project.codesProject Classification, Category Codes, Cost Centre
employee.codesJob Classification, Payroll Codes, HR Band

Historical Tracking (.activity)

Definition:
Tracks time-based changes to an entity, enabling auditability, trend analysis, and versioning.

Standardised Naming Convention: <entity>.activity
Supports Slowly Changing Dimensions (SCD)
Ensures Full Data Lineage for Compliance

Includes Status & Progress

Maintains the current and previous status of an entity, often linked to operational workflows.

Standardised Naming Convention: <entity>.status
Provides Real-Time State Information
Essential for Business Process Monitoring

Entry CodeDescription
project.activityStatus Changes, Budget Revisions, Milestone Updates
employee.activityJob Title Changes, Department Transfers, Promotions
customer.activityAddress Changes, Loyalty Tier Updates
order.activityStatus Transitions, Refunds, Modifications

Roles & Responsibilities (.roles)

🔹 Definition: Defines people and positions associated with an entity.
🔹 Examples:

Entry CodeDescription
project.rolesProject Manager, Sponsor, Stakeholders, Assigned Team Members
employee.rolesDirect Manager, HR Partner, Reporting Chain

🌟 Key Benefits of This Approach

Modular Structure: Easily extendable as business needs evolve.
Consistent Naming Conventions: Promotes readability and standardisation.
Scalability & Reusability: Reduces redundancy and improves data interoperability.
Optimised Querying: Enables efficient joins and filtering without excessive duplication.



🔍 Why This Structure Works

Metadata-Driven – Supports scalable standardisation across all DataMart views.
Optimised for Querying – Encourages modular structures in APIs & DataWarehouses.
Reusability – Field groupings are consistent across multiple domains.
Cross-Domain Insights – Easily maps financial, project, and workforce data together.

Leave a Comment