ExamFinch.com My Study

Study guide

Section 4.2: Data Quality Policy & Rules

Practice this exam

DAMA Certified Data Management Professional CDMP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & DMBoK Framework

1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles

2 Chapter 2: Data Governance (Part A)

2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures

3 Chapter 2: Data Governance (Part B)

2.4 Data Stewardship 2.5 Governance Metrics & Implementation

4 Chapter 3: Data Modeling and Design (Part A)

Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization

5 Chapter 3: Data Modeling and Design (Part B)

3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices

6 Chapter 4: Data Quality (Part A)

Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle

7 Chapter 4: Data Quality (Part B)

4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting

8 Chapter 5: Metadata Management (Part A)

5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures

9 Chapter 5: Metadata Management (Part B)

5.4 Standards and Semantics 5.5 Metadata Governance & Integration

10 Chapter 6: Master and Reference Data Management

6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards

11 Chapter 7: Data Warehousing and Business Intelligence

7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses

12 Chapter 8: Data Architecture

8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards

13 Chapter 9: Document and Content Management

9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies

14 Chapter 10: Data Integration and Interoperability

Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards

15 Chapter 11: Data Security

Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards

16 Chapter 12: Data Storage and Operations

Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations

17 Chapter 13: Big Data and Data Science

13.1 Big Data V's & Technologies

18 Chapter 14: Data Ethics

14.1 DMBoK Data Ethics Framework

19 Chapter 15: Data Management Process and Maturity

15.1 Maturity Assessment Frameworks

Section 4.2: Data Quality Policy & Rules

Key Takeaways Explain This Topic AI

A Data Quality Policy establishes the governance framework, roles, and mandates for data monitoring and remediation.

Business rules define operational constraints in plain language, while technical rules translate them into executable code (SQL, constraints, Regex).

Data profiling includes column (attribute), structure (format/pattern), and relationship (referential/cross-attribute) profiling.

Critical Data Elements (CDEs) must be prioritized during data quality requirements gathering and threshold setting.

Last updated: July 2026

Establishing Data Quality Policy & Requirements

Data quality cannot be achieved through ad-hoc clean-up efforts. It requires a formal framework of policies, requirements gathering, and rule definition. A Data Quality Policy is a formal, high-level document approved by the Data Governance Council that outlines the organization's commitments, standards, roles, and responsibilities regarding data quality. It establishes the mandate for monitoring, remediation, and reporting.

To implement this policy, the organization must first identify Critical Data Elements (CDEs) —data assets that are vital to operational execution, financial reporting, regulatory compliance, or strategic decision-making. Once CDEs are identified, business analysts and data stewards collaborate to define specific data quality requirements.

Business Rules vs. Technical Rules

Data quality requirements are articulated through rules. It is critical to distinguish between Business Rules and Technical Rules , as this distinction is a common focus of the CDMP exam.

Business Rules

Business rules are declarative statements that define or constrain some aspect of the business. They express business logic, policies, and operational requirements in plain language, independent of how the data is stored or processed. They are owned by the business.

Characteristics : Expressed in business terminology, technology-agnostic, and understandable by non-technical stakeholders.

  • Example : 'A credit card customer must be at least 18 years of age at the time of application.'
  • Technical Rules

Technical rules are the system-level implementation and translation of business rules. They are represented as SQL queries, database constraints (e.g., CHECK constraints), ETL (Extract, Transform, Load) validation logic, or regular expressions. They are executed by data quality engines or database systems.

Characteristics : Written in programming or database syntax, schema-specific, and executable by computers.

Example : CHECK (DateOfBirth <= DATEADD(year, -18, GETDATE())) or a database trigger enforcing age validation.

  • Feature Business Rules Technical Rules
  • Primary Audience Business users, regulators, data stewards Developers, database administrators, DQ engines
  • Language Plain business language (e.g., English) SQL, Regex, Python, validation schemas
  • Focus Business intent, policy compliance, logic Structural enforcement, execution, syntax
  • Ownership Business Data Stewards / Business Owners Data Engineers, Systems Analysts, DBA

Example 'Every active employee must have a supervisor.' WHERE employee_status = 'A' AND supervisor_id IS NOT NULL

Data Profiling Techniques

Data Profiling is the process of examining data from an existing source and collecting statistics or informative summaries about that data. It is the foundation of any data quality assessment, allowing data professionals to discover the actual state of data, rather than relying on outdated documentation or assumptions.

DAMA recognizes three main categories of data profiling techniques:

1. Attribute Analysis (Column Profiling)

Attribute analysis focuses on the characteristics of data within a single column. It helps identify basic structural anomalies and data distributions. Common statistics collected during column profiling include:

Cardinality : The number of unique values in the column. Low cardinality indicates lookup fields (e.g., Gender), whereas high cardinality indicates identifiers (e.g., Customer ID).

Value Distribution & Frequency : How often each value appears. This highlights anomalies (e.g., an unexpected number of 'NULL' or 'Unknown' entries).

Data Type & Length : Verifying if the actual data type matches the metadata definition (e.g., checking if a numeric column contains text values).

Min / Max / Mean / Median : Identifying statistical outliers (e.g., a transaction amount of -$5,000 or an age of 999).

2. Structure Profiling (Format & Pattern Analysis)

Structure profiling evaluates whether the values in a column conform to a specific expected pattern or structural format.

Pattern Matching : Using regular expressions (Regex) to ensure strings match standard templates.

Example : Checking if telephone numbers conform to the North American Numbering Plan pattern (###) ###-#### . If a value is stored as 123-45-678 , it fails the pattern analysis.

3. Relationship Profiling (Cross-Attribute & Referential Analysis)

Relationship profiling examines the connections and dependencies between multiple columns within the same table or across different tables.

Referential Integrity Analysis : Ensuring that foreign key values in a child table exist as primary keys in the parent table. For example, verifying that every Order.CustomerID points to a valid Customer.CustomerID .

Functional Dependency Analysis : Checking if the value of one attribute determines the value of another. For example, if the ZIP_Code is '10001', the City must be 'New York'. A violation occurs if the database contains a record with ZIP_Code '10001' and City 'Los Angeles'.

Redundancy Analysis : Identifying overlapping data across different systems to facilitate integration and master data consolidation.

The Data Quality Requirements Gathering Process

Defining data quality requirements is a structured process that bridges the gap between business needs and technical enforcement. The process typically involves five key steps:

Identify Stakeholders & Data Consumers : Determine who uses the data, how they use it, and what downstream systems rely on it.

Define Critical Data Elements (CDEs) : Because resources are limited, organizations cannot monitor every field. They must prioritize CDEs—data points that are critical to operational, financial, or regulatory success.

Specify Business Rules : Work with stakeholders to define business expectations (e.g., 'A customer cannot have a shipping address without a corresponding postal code').

Establish Data Quality Thresholds : A threshold is the minimum acceptable level of quality for a specific metric. For example, the threshold for completeness on a critical billing field might be set to 99.9%, whereas the threshold for an optional field, like middle_name , might be set to 60%.

Translate to Technical Rules & Deploy : Engineers write the code, constraints, or DQ engine configurations to continuously monitor the data against these thresholds, outputting alerts when thresholds are breached.