CDMP — DAMA Data Management Fundamentals Quick Reference
Compact CDMP Data Management Fundamentals reference for DAMA concepts, knowledge areas, governance, quality, metadata, architecture, and exam distinctions.
Exam Identity and How to Use This Reference
This Quick Reference supports independent preparation for the DAMA International DAMA CDMP Data Management Fundamentals, exam code CDMP. It is designed for fast review of the data management concepts, distinctions, deliverables, and decision points commonly associated with DAMA-style data management practice.
Use it to check:
- What each data management knowledge area is responsible for.
- Which artifacts, roles, and processes belong together.
- How to distinguish governance, architecture, quality, metadata, MDM, integration, warehousing, and security scenarios.
- Common exam traps where similar terms are intentionally contrasted.
Core DAMA Data Management Frame
Data Management in One View
| Concept | Exam-ready meaning | Common trap |
|---|---|---|
| Data management | Development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance data and information assets | Not just database administration or analytics |
| Data as an asset | Data has value, risk, lifecycle, ownership/accountability, and quality expectations | Treating data as an IT byproduct only |
| Data lifecycle | Creation/acquisition, storage, use, sharing, retention, archive, disposal | Lifecycle is broader than system development lifecycle |
| Data management function | Cross-functional business and IT discipline | Not owned only by a central data team |
| Knowledge area | A discipline such as Data Governance, Data Quality, Metadata, Security, etc. | Knowledge areas overlap; they are not isolated silos |
| Data strategy | Direction and priorities for using data to support business goals | Not a project plan or a technology roadmap alone |
| Data management program | Organized capabilities, roles, policies, processes, and metrics to manage data | Not a one-time cleanup effort |
DAMA-Style Knowledge Areas
| Knowledge area | Primary purpose | Typical artifacts | High-yield distinction |
|---|---|---|---|
| Data Governance | Authority, accountability, policy, decision rights, issue escalation | Policies, standards, stewardship model, council charters, decision logs | Sets rules and accountability; does not perform every operational data task |
| Data Architecture | Enterprise view of data assets and flows aligned to business strategy | Data architecture, subject-area model, data flow maps, target-state roadmap | Describes what data exists and how it should be organized across the enterprise |
| Data Modeling and Design | Represent data requirements and structures at conceptual, logical, and physical levels | ERDs, dimensional models, normalization design, naming standards | Modeling is about structure and meaning, not only database implementation |
| Data Storage and Operations | Manage physical persistence, availability, performance, backup, recovery, and operations | Database standards, operational procedures, backup/recovery plans | Focuses on running and protecting stored data assets |
| Data Security | Protect confidentiality, integrity, and availability through controls | Access policies, classification, encryption rules, audit logs | Security is risk-based and applies across lifecycle, not only login control |
| Data Integration and Interoperability | Move, combine, exchange, and synchronize data across systems | ETL/ELT design, APIs, mappings, interface specs, lineage | Integration is about consistency and movement between systems |
| Document and Content Management | Manage unstructured/semi-structured documents, records, and content | Taxonomies, retention schedules, content repositories, records policies | Content is not always row/column structured data |
| Reference and Master Data | Manage shared core entities and valid value sets | Golden records, match/merge rules, hierarchies, code sets | MDM is about core business entities; reference data is controlled value lists |
| Data Warehousing and BI | Support reporting, analytics, decision support, and historical analysis | Data warehouse, marts, cubes, semantic layer, reports, dashboards | Optimized for analysis, not transaction processing |
| Metadata Management | Manage information about data meaning, origin, rules, structure, and usage | Business glossary, data catalog, lineage, technical metadata | Metadata enables understanding, control, traceability, and reuse |
| Data Quality | Define, measure, monitor, and improve fitness for purpose | DQ rules, scorecards, issue logs, remediation plans | Quality depends on business use, not abstract perfection |
| Big Data and Data Science | Use large, varied, fast, or complex data for advanced analytics and models | Data lakes, feature sets, ML pipelines, analytic sandboxes | Adds scale/variety/analytics complexity; governance still applies |
| Data Management Maturity | Assess capability levels and improvement priorities | Maturity assessments, gap analysis, roadmap | Measures capability, not data quality alone |
| Data Management Organization and Roles | Define responsibilities, accountabilities, and operating model | RACI, role descriptions, committees, stewardship network | Organizational design supports execution of governance and management |
| Organizational Change Management | Drive adoption of data practices, standards, and behaviors | Stakeholder plans, communications, training, resistance management | Data initiatives fail without adoption, not just technical delivery |
High-Yield Distinctions
Governance vs Management vs Stewardship
| Term | Main question answered | Typical owner/accountable party | Example |
|---|---|---|---|
| Data Governance | Who has authority and what rules apply? | Data governance council, executives, data owners | Approving a policy that customer data must have an assigned owner |
| Data Management | How are data assets planned, built, operated, controlled, and improved? | Data management professionals, IT, business teams | Implementing metadata, quality monitoring, MDM, integration, storage |
| Data Stewardship | Who ensures rules are applied and issues are resolved for specific data? | Business or technical stewards | Reviewing DQ exceptions for customer address completeness |
| Data Ownership | Who is accountable for data decisions and value/risk? | Business data owner | Approving definition of “active customer” |
| Data Custodianship | Who technically safeguards and operates data? | IT/platform/database/security teams | Applying access controls and backups |
Policy, Standard, Procedure, Guideline
| Artifact | Force | Purpose | Example |
|---|---|---|---|
| Policy | Mandatory, high-level | State required rule or intent | Sensitive data must be classified and protected |
| Standard | Mandatory, specific | Define uniform requirements | Customer identifiers must follow approved format |
| Procedure | Mandatory or controlled process | Explain steps to perform work | Steps to request access to restricted data |
| Guideline | Recommended | Provide advice or preferred practice | Suggested naming pattern for analytic data sets |
Conceptual, Logical, Physical Models
| Model level | Audience | Contains | Does not usually contain |
|---|---|---|---|
| Conceptual | Business stakeholders, architects | Major subject areas, entities, relationships, business vocabulary | Database columns, indexes, storage details |
| Logical | Data analysts, modelers, architects | Entities, attributes, relationships, keys, normalization, business rules | Platform-specific storage implementation |
| Physical | DBAs, engineers, developers | Tables, columns, datatypes, indexes, partitions, constraints | Purely business-only abstractions |
OLTP vs OLAP
| Characteristic | OLTP | OLAP / Data Warehouse |
|---|---|---|
| Purpose | Run business transactions | Analyze historical and integrated data |
| Data shape | Current, detailed, normalized | Historical, integrated, often dimensional |
| Workload | Inserts/updates/deletes, high concurrency | Reads, aggregations, trend analysis |
| Users | Operational applications, front-line users | Analysts, managers, decision makers |
| Design priority | Integrity and transaction performance | Query performance and usability |
| Example | Order entry system | Sales trend dashboard |
Data Governance Quick Reference
Governance Components
| Component | What it does | Exam clue |
|---|---|---|
| Data governance strategy | Sets direction, scope, outcomes, and alignment to business goals | “Enterprise approach,” “program direction,” “business alignment” |
| Decision rights | Defines who can approve definitions, standards, access, changes | “Who has authority?” |
| Data ownership | Assigns accountability for data domains or subject areas | “Accountable business role” |
| Stewardship | Operationalizes governance decisions and issue resolution | “Day-to-day data responsibility” |
| Policies and standards | Formalize expected behavior and controls | “Consistent rules” |
| Issue management | Captures, prioritizes, escalates, and resolves data problems | “Escalation path” |
| Metrics | Measures adoption, quality, compliance, and value | “How do we know it works?” |
| Communications | Builds awareness and adoption | “Stakeholder buy-in” |
Governance Operating Model Patterns
| Pattern | When useful | Risk |
|---|---|---|
| Centralized | Strong consistency, regulated or enterprise-wide control needs | May be slow or detached from business domains |
| Decentralized | Business units need autonomy and local responsiveness | Inconsistent definitions and duplicated effort |
| Federated | Enterprise standards plus domain-level execution | Requires clear accountability and coordination |
| Committee/council-based | Cross-functional decisions and escalation | Can become bureaucratic without decision authority |
| Stewardship network | Broad operational adoption | Needs training, role clarity, and management support |
Governance Scenario Decisions
| Scenario | Best governance response |
|---|---|
| Different departments define “customer” differently | Establish authoritative business definition, owner, glossary entry, and usage context |
| Reports conflict across departments | Investigate lineage, source definitions, transformations, and calculation rules |
| No one approves changes to critical data definitions | Define data ownership and decision rights |
| Repeated unresolved DQ defects | Implement issue management, stewardship accountability, root-cause remediation |
| Business resists new data standards | Use change management, stakeholder engagement, and value-based communication |
| Sensitive data is widely accessible | Apply data classification, access policy, security controls, and monitoring |
Data Architecture
Architecture Views
| View | Focus | Common artifacts |
|---|---|---|
| Enterprise data architecture | Organization-wide data assets, subject areas, flows, and principles | Enterprise data model, capability map, data domain model |
| Business/data domain view | Core business concepts and their relationships | Subject-area model, canonical definitions |
| Application/data flow view | Movement of data between systems | Data flow diagrams, system context diagrams, interface maps |
| Technology/platform view | Data stores, platforms, integration tools, storage technologies | Platform architecture, deployment patterns |
| Target-state roadmap | Transition from current to desired capabilities | Gap analysis, migration roadmap |
Architecture Principles
| Principle | Practical interpretation |
|---|---|
| Business alignment | Data architecture supports business strategy and capabilities |
| Shared data | Common data should be reusable and consistently defined |
| Data quality by design | Validation, controls, and ownership should be built into architecture |
| Metadata-driven management | Meaning, lineage, and controls should be documented and discoverable |
| Security and privacy by design | Protection is embedded early, not bolted on later |
| Lifecycle management | Retention, archive, and disposal are planned |
| Interoperability | Systems exchange data using agreed structures and semantics |
Architecture vs Modeling vs Integration
| If the question focuses on… | Think first of… |
|---|---|
| Enterprise subject areas and target state | Data Architecture |
| Entity attributes, relationships, keys | Data Modeling and Design |
| Mapping source to target and moving data | Data Integration and Interoperability |
| Enterprise-approved definitions | Data Governance and Metadata |
| Shared customer/product/vendor records | Reference and Master Data |
| Historical analytical store | Data Warehousing and BI |
Data Modeling and Design
Modeling Terms
| Term | Meaning | Trap |
|---|---|---|
| Entity | Thing of business interest | Not necessarily a physical table |
| Attribute | Fact or property about an entity | Should have clear definition and domain |
| Relationship | Association between entities | Cardinality and optionality matter |
| Cardinality | Number of instances that may participate | One-to-one, one-to-many, many-to-many |
| Optionality | Whether participation is required | Mandatory vs optional relationship |
| Primary key | Unique identifier for a record/entity instance | Natural or surrogate depending on design |
| Foreign key | Attribute referencing another table/entity key | Enforces referential integrity in physical design |
| Normalization | Reduce redundancy and update anomalies | Too much normalization may impair analytic usability |
| Denormalization | Add redundancy for performance/usability | Increases maintenance and consistency risk |
| Domain | Permitted set or type of values | Supports validation and consistency |
| Constraint | Rule enforced on data | May be business, logical, or physical |
Normalization Review
| Normal form concept | Core idea | Typical issue prevented |
|---|---|---|
| 1NF | Values are atomic; repeating groups removed | Multiple values in one field |
| 2NF | Non-key attributes depend on whole key | Partial dependency on part of composite key |
| 3NF | Non-key attributes depend only on the key | Transitive dependency |
| Higher forms | Address more complex dependency issues | Subtle redundancy and anomaly cases |
Dimensional Modeling
| Term | Meaning | Example |
|---|---|---|
| Fact table | Numeric measurements at a defined grain | Sales amount by order line |
| Dimension table | Descriptive context for facts | Date, product, customer, store |
| Grain | Lowest level of detail represented by a fact table | One row per order line per product |
| Star schema | Fact table connected to denormalized dimensions | Common BI design |
| Snowflake schema | Dimensions normalized into related tables | Less redundancy, more joins |
| Slowly changing dimension | Method for handling dimension attribute changes over time | Customer address history |
| Conformed dimension | Shared dimension used consistently across facts/marts | Common date or product dimension |
Modeling Traps
| Trap | Correct exam reasoning |
|---|---|
| Treating conceptual model as physical schema | Conceptual models communicate business meaning, not implementation details |
| Starting physical design before requirements | Modeling should be driven by business rules and data requirements |
| Assuming all redundancy is bad | Redundancy may be deliberately introduced for performance or analytics |
| Ignoring grain in fact design | Grain must be declared before selecting facts and dimensions |
| Confusing master data with dimensional data | Master data manages authoritative core entities; dimensions provide analytic context |
Data Storage and Operations
Operational Responsibilities
| Area | Focus | Examples |
|---|---|---|
| Database operations | Availability, performance, capacity, monitoring | Tuning, backup jobs, index maintenance |
| Backup and recovery | Restore data after failure or corruption | Recovery procedures, restore tests |
| Data retention | Keep data as long as required by policy/business need | Retention schedules, archive strategy |
| Archiving | Move inactive data to lower-cost or long-term storage | Historical transaction archive |
| Disposal | Defensible deletion at end of lifecycle | Secure deletion, disposal evidence |
| Performance management | Ensure workloads meet service expectations | Query tuning, resource monitoring |
| Data environment management | Manage development, test, production data safely | Refreshes, masking, change control |
Backup and Recovery Terms
| Term | Meaning |
|---|---|
| Backup | Copy of data for restoration |
| Restore | Process of bringing backup data back into an environment |
| Recovery | Returning service/data to usable state after failure |
| RPO | Maximum acceptable data loss, expressed as time |
| RTO | Maximum acceptable time to restore service |
| Point-in-time recovery | Restore to a specific prior moment |
| Disaster recovery | Broader recovery of systems/processes after major disruption |
| Business continuity | Maintaining critical business operations during disruption |
Data Security
Security Concepts
| Concept | Meaning | Exam cue |
|---|---|---|
| Confidentiality | Prevent unauthorized disclosure | Sensitive data exposure |
| Integrity | Prevent unauthorized or improper modification | Tampering, incorrect changes |
| Availability | Ensure authorized access when needed | Outage, resilience, denial of service |
| Authentication | Verify identity | Login, identity proof |
| Authorization | Grant permitted actions | Roles, privileges, access rights |
| Least privilege | Grant only access needed | Over-permissioned users |
| Segregation of duties | Separate conflicting responsibilities | Avoid one person controlling entire process |
| Data classification | Categorize data by sensitivity/value/risk | Public, internal, confidential, restricted |
| Encryption | Protect data by encoding it | At rest, in transit |
| Masking | Obscure sensitive data, often for non-production or display | Test data, partial display |
| Tokenization | Replace sensitive value with non-sensitive token | Payment or identifier protection |
| Auditing | Track access and changes | Evidence, monitoring, compliance support |
Security Control Types
| Control type | Purpose | Examples |
|---|---|---|
| Preventive | Stop unwanted event | Access control, encryption, input validation |
| Detective | Identify event after or during occurrence | Logging, monitoring, anomaly detection |
| Corrective | Restore or remediate | Incident response, restore, patching |
| Administrative | People/process rules | Policies, training, procedures |
| Technical | Technology-enforced controls | IAM, database permissions, encryption |
| Physical | Facility/media protection | Locked rooms, secure disposal |
Security Decision Points
| Scenario | Likely control |
|---|---|
| Users should see only data for their region | Role-based or attribute-based access control |
| Developers need production-like data without sensitive values | Data masking or synthetic data |
| Data moves between systems | Encryption in transit and secure interface controls |
| Data stored in a database contains sensitive fields | Encryption at rest, column-level controls, access restrictions |
| Need evidence of who changed data | Audit logging and change tracking |
| Business must know sensitivity before applying controls | Data classification |
Data Integration and Interoperability
Integration Patterns
| Pattern | Best for | Watch for |
|---|---|---|
| Batch ETL | Scheduled movement and transformation before loading | Latency, reconciliation |
| ELT | Load first, transform in target platform | Governance and target platform capacity |
| Real-time/event streaming | Low-latency event processing | Ordering, replay, monitoring, schema evolution |
| API-based integration | Controlled service-to-service exchange | Versioning, security, throttling, contract management |
| Data replication | Copy/sync data between stores | Consistency, conflict handling |
| Virtualization/federation | Query data without physically moving it | Performance, source availability, semantic consistency |
| Messaging/queueing | Decoupled asynchronous exchange | Delivery guarantees, idempotency |
Integration Artifacts
| Artifact | Purpose |
|---|---|
| Source-to-target mapping | Defines how fields transform from source to destination |
| Interface specification | Describes exchange structure, format, protocol, frequency |
| Data contract | Agreed expectations for data structure, semantics, and changes |
| Transformation rules | Business/technical logic applied during movement |
| Reconciliation report | Confirms completeness and consistency after transfer |
| Lineage documentation | Tracks origin, movement, and transformation of data |
| Error handling rules | Define rejects, retries, exception management |
Integration Traps
| Trap | Correct reasoning |
|---|---|
| Assuming integration fixes data quality | Integration can expose or move poor-quality data; quality rules and ownership are still needed |
| Ignoring semantic differences | Same field name may mean different things across systems |
| No lineage for transformed data | Users cannot trust reports if origin and transformations are opaque |
| Treating APIs as only technical | APIs require contracts, governance, security, and lifecycle management |
| Duplicating data without synchronization rules | Copies diverge unless ownership and update rules are clear |
Document and Content Management
Structured vs Semi-Structured vs Unstructured
| Data type | Description | Examples | Management focus |
|---|---|---|---|
| Structured | Organized in defined schema | Relational tables, coded fields | Modeling, integrity, query performance |
| Semi-structured | Has tags/markers but flexible schema | XML, JSON, emails with metadata | Parsing, schema evolution, metadata |
| Unstructured | No fixed data model | Documents, images, audio, video | Classification, search, retention, content lifecycle |
Content and Records Terms
| Term | Meaning |
|---|---|
| Document management | Control creation, storage, retrieval, and lifecycle of documents |
| Content management | Broader management of digital content for use and publication |
| Records management | Manage records as evidence of business activity |
| Taxonomy | Controlled classification structure |
| Ontology | Formal representation of concepts and relationships |
| Retention schedule | Rules for how long content/records are kept |
| Legal hold | Preservation requirement that suspends normal disposal when needed |
| Version control | Management of revisions and history |
| eDiscovery | Identification and production of electronically stored information |
Reference and Master Data
Master Data vs Reference Data
| Aspect | Master data | Reference data |
|---|---|---|
| Meaning | Core business entities shared across processes | Controlled lists of valid values/classifications |
| Examples | Customer, product, vendor, employee, location | Country codes, currency codes, status codes |
| Management focus | Identity resolution, survivorship, hierarchy, golden record | Standard values, code mappings, valid value governance |
| Change pattern | Can be complex and frequent | Often more stable, but changes must be controlled |
| Main risk | Duplicate/inconsistent core entities | Inconsistent coding and interpretation |
MDM Concepts
| Term | Meaning |
|---|---|
| Golden record | Best authoritative representation of an entity |
| Match | Identify records that may represent same entity |
| Merge | Combine duplicate records according to rules |
| Survivorship | Determine which source value wins for an attribute |
| Hierarchy management | Manage parent-child relationships among master entities |
| Identity resolution | Determine whether records refer to the same real-world entity |
| Data stewardship | Review exceptions, approve merges, maintain rules |
| Registry style | Maintains cross-reference/index to source records |
| Consolidation style | Creates consolidated view for reporting/analytics |
| Coexistence style | MDM hub and sources share ongoing maintenance |
| Transaction style | MDM hub becomes authoritative system of entry for master data |
MDM Style Selection
| Requirement | Likely style |
|---|---|
| Need cross-reference without replacing source systems | Registry |
| Need consolidated reporting view of customers/products | Consolidation |
| Need shared maintenance across hub and source systems | Coexistence |
| Need central authoritative creation/update of master data | Transaction |
| Need quick visibility into duplicates with minimal disruption | Registry or consolidation |
| Need strong operational control over entity lifecycle | Transaction or coexistence |
Data Warehousing and Business Intelligence
Warehouse Architecture Terms
| Term | Meaning |
|---|---|
| Data warehouse | Integrated, historical, subject-oriented data store for analytics |
| Data mart | Subset of warehouse data for department/process/domain |
| Operational data store | Integrated current/near-current operational data store |
| Staging area | Temporary landing area for loading/transformation |
| Semantic layer | Business-friendly abstraction over data structures |
| Cube | Multidimensional analytic structure |
| Dashboard | Visual summary of metrics and trends |
| Report | Structured output answering recurring business questions |
| KPI | Key performance indicator linked to business objective |
Warehouse vs Lake vs Lakehouse
| Platform | Best fit | Governance concern |
|---|---|---|
| Data warehouse | Curated, structured, trusted reporting and BI | Definitions, lineage, quality, access control |
| Data lake | Store large volumes of raw/diverse data | Avoid unmanaged “data swamp” through metadata and governance |
| Lakehouse | Combine lake flexibility with warehouse-like management features | Clear zones, quality controls, catalog, security |
| ODS | Current integrated operational reporting | Latency, operational impact, source consistency |
BI Metric Traps
| Trap | Correct reasoning |
|---|---|
| KPI without business objective | A KPI should measure progress toward a defined goal |
| Dashboard as governance solution | Dashboards display data; governance defines meaning, accountability, and rules |
| Report disagreement treated as visualization issue | Investigate source data, definitions, transformations, and lineage |
| Data mart built independently without conformed dimensions | Creates inconsistent metrics across departments |
Metadata Management
Metadata Categories
| Category | Describes | Examples |
|---|---|---|
| Business metadata | Business meaning and usage | Definitions, business rules, owners, policies |
| Technical metadata | Technical structure and processing | Tables, columns, datatypes, schemas, jobs |
| Operational metadata | Runtime and processing information | Load times, error counts, usage logs |
| Process metadata | Data movement and transformations | ETL mappings, workflow steps |
| Governance metadata | Accountability and controls | steward, classification, retention rule |
| Lineage metadata | Origin and transformation path | Source-to-report trace |
| Usage metadata | How data is accessed and used | Query frequency, report usage |
Metadata Tools and Artifacts
| Artifact/tool | Purpose |
|---|---|
| Business glossary | Shared definitions for business terms |
| Data dictionary | Technical definitions of data structures |
| Data catalog | Searchable inventory of data assets and metadata |
| Metadata repository | Central store for metadata |
| Lineage tool | Shows where data came from and how it changed |
| Data profiling tool | Analyzes actual data values and patterns |
| Classification tags | Identify sensitivity, domain, quality, retention, ownership |
Glossary vs Dictionary vs Catalog
| Item | Primary audience | Focus |
|---|---|---|
| Business glossary | Business and governance users | Meaning, definition, ownership, approved terms |
| Data dictionary | Developers, DBAs, analysts | Technical fields, tables, datatypes, constraints |
| Data catalog | Broad data consumers | Discoverability, metadata, lineage, usage, access path |
Data Quality
Data Quality Dimensions
| Dimension | Question answered | Example check |
|---|---|---|
| Accuracy | Does data correctly represent reality? | Address matches verified source |
| Completeness | Are required values present? | Customer record has required contact fields |
| Consistency | Do values agree across systems/rules? | Same customer status in CRM and billing |
| Timeliness | Is data available/current when needed? | Daily sales loaded before morning reporting |
| Validity | Does data conform to format/domain/rules? | Date is valid; status is from approved list |
| Uniqueness | Are duplicates avoided? | One active customer record per real customer |
| Integrity | Are relationships and constraints maintained? | Order references valid customer |
| Conformity | Does data follow standards? | Phone format follows standard pattern |
| Reasonableness | Is value plausible? | Birth date not in future |
Data Quality Process
| Step | Purpose | Output |
|---|---|---|
| Define requirements | Identify fitness-for-purpose expectations | DQ rules, thresholds, critical data elements |
| Profile data | Understand actual values and patterns | Profiling results, anomalies |
| Measure quality | Quantify against rules/dimensions | DQ scorecards, metrics |
| Analyze root cause | Identify why defects occur | Root-cause analysis |
| Remediate | Correct data and/or process | Cleansed data, process fixes |
| Monitor | Detect recurrence and trends | Alerts, dashboards |
| Prevent | Embed controls upstream | Validation, training, improved process |
Data Quality Formulas
Completeness rate:
\[ \text{Completeness Rate} = \frac{\text{Number of populated required values}}{\text{Number of required values expected}} \times 100 \]Defect rate:
\[ \text{Defect Rate} = \frac{\text{Number of records failing a rule}}{\text{Total records tested}} \times 100 \]Duplicate rate:
\[ \text{Duplicate Rate} = \frac{\text{Number of duplicate records identified}}{\text{Total records evaluated}} \times 100 \]DQ Scenario Decisions
| Scenario | Best response |
|---|---|
| Missing required fields in a source application | Add validation and process controls at capture point |
| Different customer counts in two reports | Compare definitions, filters, source lineage, and transformations |
| Duplicate customer records | Use matching rules, MDM/steward review, prevention at entry |
| Valid values differ by system | Govern reference data and code mappings |
| Dashboard shows stale data | Check load timeliness, SLAs, operational metadata |
| Quality score improves only after manual cleanup | Address root cause and preventive controls, not just correction |
Big Data and Data Science
Big Data Characteristics
| Characteristic | Meaning |
|---|---|
| Volume | Large quantities of data |
| Velocity | Speed of generation, ingestion, or processing |
| Variety | Multiple formats and structures |
| Veracity | Trustworthiness and uncertainty |
| Value | Business benefit derived from use |
Analytics Types
| Type | Question | Example |
|---|---|---|
| Descriptive | What happened? | Monthly sales report |
| Diagnostic | Why did it happen? | Root-cause analysis of churn |
| Predictive | What is likely to happen? | Churn prediction model |
| Prescriptive | What should be done? | Recommended next best offer |
Data Science Lifecycle
| Stage | Focus | Governance touchpoints |
|---|---|---|
| Problem framing | Define business objective and success criteria | Business ownership, ethical use |
| Data acquisition | Identify and collect data | Consent/permissions, source quality, lineage |
| Preparation | Clean, transform, engineer features | DQ rules, reproducibility |
| Modeling | Train and evaluate models | Bias, explainability, validation |
| Deployment | Operationalize model | Monitoring, access, change control |
| Monitoring | Track performance and drift | Metrics, auditability, retraining triggers |
Data Science Traps
| Trap | Correct reasoning |
|---|---|
| More data always means better model | Relevance, quality, bias, and representativeness matter |
| Data lake eliminates governance need | Big data requires metadata, quality, security, lifecycle controls |
| Model accuracy is the only concern | Ethics, explainability, bias, operational fit, and monitoring also matter |
| Experiment data can ignore lineage | Reproducibility requires data and process traceability |
Data Ethics and Responsible Data Handling
| Principle | Practical meaning |
|---|---|
| Respect for persons | Consider individual rights, expectations, and impacts |
| Beneficence | Seek benefit and reduce harm |
| Justice | Avoid unfair treatment or discriminatory outcomes |
| Transparency | Be clear about data use where appropriate |
| Accountability | Assign responsibility for decisions and outcomes |
| Minimization | Use only data needed for the purpose |
| Purpose alignment | Use data consistently with legitimate business purpose |
| Risk awareness | Evaluate misuse, bias, exposure, and downstream impact |
Ethical Red Flags
| Red flag | Why it matters |
|---|---|
| Using data for a purpose unrelated to collection context | Violates trust and may create legal/compliance risk |
| Combining datasets to infer sensitive attributes | Creates hidden privacy and fairness risks |
| No accountability for algorithmic decisions | Weakens auditability and remediation |
| Ignoring biased or unrepresentative training data | Can produce unfair or invalid outcomes |
| Excessive retention | Increases risk and may conflict with policy |
| “Because we can” reasoning | Capability does not equal appropriate use |
Data Management Maturity
Maturity Assessment Focus Areas
| Area assessed | What to look for |
|---|---|
| Strategy | Data goals aligned to business priorities |
| Governance | Decision rights, policies, ownership, stewardship |
| Architecture | Enterprise data view and target-state planning |
| Quality | Defined rules, measurement, remediation, monitoring |
| Metadata | Catalog/glossary/lineage and active metadata use |
| Security | Classification, access control, monitoring |
| Organization | Roles, responsibilities, funding, operating model |
| Processes | Repeatable, measured, improved practices |
| Tools | Supporting technology aligned to processes |
| Culture | Data literacy, adoption, accountability |
Maturity vs Capability vs Performance
| Term | Meaning |
|---|---|
| Maturity | Degree to which practices are defined, managed, measured, and improved |
| Capability | Ability to perform a data management function |
| Performance | Results achieved by executing the capability |
| Gap analysis | Difference between current and desired state |
| Roadmap | Sequenced improvement plan |
Organization, Roles, and Change Management
Common Roles
| Role | Primary responsibility |
|---|---|
| Executive sponsor | Provides authority, funding, and strategic support |
| Data governance council | Makes cross-functional data decisions and resolves escalations |
| Chief data officer / senior data leader | Leads enterprise data strategy and program direction where established |
| Data owner | Business accountability for data domain or critical data |
| Business data steward | Business definitions, quality rules, issue resolution |
| Technical data steward | Technical metadata, mappings, lineage, platform details |
| Data architect | Enterprise and solution data architecture |
| Data modeler | Conceptual/logical/physical models |
| DBA / data platform administrator | Storage, performance, backup, operational control |
| Data engineer | Pipelines, integration, transformation, data products |
| BI developer / analyst | Reports, dashboards, semantic models |
| Data quality analyst | Profiling, measurement, issue tracking |
| Information security professional | Security policy, controls, risk management |
| Records/content manager | Document, content, retention, records lifecycle |
RACI Basics
| Letter | Meaning | Exam note |
|---|---|---|
| R | Responsible | Performs the work |
| A | Accountable | Owns outcome and final decision; ideally one accountable party |
| C | Consulted | Provides input before decision/action |
| I | Informed | Kept aware after decision/action |
Change Management for Data Programs
| Need | Practical action |
|---|---|
| Stakeholder buy-in | Identify affected groups and explain value |
| Adoption of standards | Train, communicate, embed in workflows |
| Resistance management | Address incentives, workload, and concerns |
| Sustained behavior change | Use metrics, leadership support, reinforcement |
| Data literacy | Teach definitions, quality expectations, and responsible use |
| Governance participation | Clarify time commitment, authority, and escalation paths |
Cross-Knowledge-Area Scenario Matrix
| If the prompt says… | Most likely area | Why |
|---|---|---|
| “Who is authorized to define this term?” | Data Governance | Decision rights and ownership |
| “What does this business term mean?” | Metadata Management | Business glossary and definitions |
| “Where did this report value come from?” | Metadata Management / Integration | Lineage and transformations |
| “Why are there duplicate customer records?” | MDM / Data Quality | Entity resolution and duplicate prevention |
| “How should customer data be structured?” | Data Modeling and Design | Entities, attributes, keys, relationships |
| “How do systems exchange order data?” | Data Integration and Interoperability | Interfaces, mappings, APIs, ETL |
| “Which platform stores history for analytics?” | Data Warehousing and BI | Historical integrated reporting |
| “How do we restrict access to sensitive data?” | Data Security | Classification, authorization, controls |
| “How long should records be retained?” | Records/Content Management and Governance | Retention rules and lifecycle |
| “How mature is our data program?” | Data Management Maturity | Capability assessment and roadmap |
| “How do we get people to follow new data standards?” | Organizational Change Management | Adoption and behavior change |
Common Exam Traps and Corrections
| Trap | Better answer |
|---|---|
| Governance equals data quality | Governance sets accountability and rules; DQ measures and improves fitness for use |
| Metadata equals data dictionary only | Metadata includes business, technical, operational, lineage, governance, and usage information |
| MDM equals data warehouse | MDM manages authoritative core entities; warehouses support analytics |
| Data architecture equals database design | Architecture covers enterprise data assets, flows, principles, and target state |
| Data security belongs only to IT | Security requires business classification, risk decisions, and technical controls |
| Data quality means 100% perfect data | Quality means fit for purpose at acceptable cost/risk |
| Data lake means raw data without controls | Data lakes still need cataloging, security, lineage, quality, and lifecycle management |
| Data owner performs all data work | Owner is accountable; stewards/custodians/engineers perform specific tasks |
| Reports are wrong because the BI tool is wrong | Check definitions, sources, transformations, lineage, and quality first |
| Cleanup is enough to solve quality | Prevent recurrence through upstream process and control changes |
| Reference data and master data are interchangeable | Reference data is valid value sets; master data is core business entities |
| Logical model is platform-specific | Physical model is platform-specific; logical model is business-structured but implementation-neutral |
Compact Term Table
| Term | Quick meaning |
|---|---|
| Critical data element | Data element important to business operations, decisions, risk, or reporting |
| Authoritative source | Trusted source designated for a data element or domain |
| System of record | Official source for a particular business transaction or data set |
| System of entry | System where data is initially captured |
| Data lineage | Path from origin through movement, transformation, and use |
| Data provenance | Origin and history of data |
| Data profiling | Analysis of actual data values, patterns, completeness, uniqueness, validity |
| Data cleansing | Correcting or standardizing defective data |
| Data enrichment | Adding value by appending or deriving additional data |
| Data standardization | Applying consistent formats, codes, names, or structures |
| Data stewardship | Accountability-in-action for definitions, quality, and issue resolution |
| Data domain | Logical grouping of related data, such as customer or product |
| Data product | Packaged data asset designed for consumption and reuse |
| Data contract | Agreement about structure, semantics, quality, and change expectations |
| Data classification | Categorization by sensitivity, value, or risk |
| Semantic consistency | Same meaning across contexts |
| Canonical model | Standard shared representation for exchange or integration |
| CRUD matrix | Create, read, update, delete mapping between processes and data |
| Referential integrity | Valid relationships between related records |
| Survivorship rule | Rule determining preferred source value in MDM |
| Conformed dimension | Dimension shared consistently across analytic structures |
| Data lineage gap | Missing traceability between source and consumption |
| Data swamp | Poorly governed data lake with low discoverability and trust |
Fast Review Checklist
Before Answering a Scenario Question
- Identify the business problem: authority, meaning, movement, quality, security, analytics, or storage.
- Separate accountability from execution.
- Look for lifecycle stage: create, store, use, share, retain, dispose.
- Check whether the question asks for policy, process, artifact, role, or technology.
- Prefer prevention and root-cause correction over after-the-fact cleanup.
- Prefer business-aligned definitions and ownership over purely technical fixes.
- Do not ignore metadata, lineage, or stewardship when trust is the issue.
Last-Pass Knowledge Area Cues
| Cue word or phrase | Think |
|---|---|
| Authority, accountability, policy | Governance |
| Subject area, target state, enterprise view | Architecture |
| Entity, attribute, relationship, key | Modeling |
| Backup, recovery, performance, retention | Storage and Operations |
| Confidentiality, access, classification | Security |
| ETL, API, source-to-target, exchange | Integration |
| Documents, records, taxonomy, retention | Content Management |
| Customer/product/vendor golden record | MDM |
| Valid codes, value lists | Reference Data |
| Dashboard, KPI, dimensional model | DW/BI |
| Glossary, catalog, lineage | Metadata |
| Accuracy, completeness, profiling | Data Quality |
| Model, prediction, data lake, features | Big Data/Data Science |
| Maturity, capability, roadmap | Maturity Assessment |
| Adoption, training, resistance | Change Management |
Practical Next Step
Use this Quick Reference as a checklist while answering practice questions for the DAMA International DAMA CDMP Data Management Fundamentals (CDMP) exam. For each missed question, classify the miss by knowledge area, then write the one distinction that would have led you to the correct answer.