CDMP Fundamentals: 6-Week Study Guide

1 Progress overview

You start on Monday 3 November with four study weeks and one buffer week, then sit the exam in week 6 (8 to 14 December). Tick each task in the plan as you finish it; this page fills in the Done and Left columns as you tick, and saves your ticks in this browser.

Practice test milestones: baseline on Mon 3 Nov (day 1), timed on Sun 16 Nov (day 14, target 70%), timed on Fri 28 Nov (day 26, target 85%), and a final timed test on Thu 4 Dec (target 90%).

2 Exam at a glance

This plan assumes the CDMP Data Management Fundamentals exam, based on the DAMA-DMBOK2 (2nd edition, revised 2024). Your 85% target clears the 80% Fundamentals score that CDMP Master requires, so aim to score 90% on practice tests to leave a buffer. Practitioner and Master also need two specialist exams and work experience; Fundamentals alone gives Associate.

Open book helps less than it sounds: with under a minute per question, you can afford to look up maybe 10 to 15 answers. Everything else has to be recall, so the plan below front-loads understanding and ends with timed practice.

3 Where the marks are

Four areas carry 44% of the exam, and the top seven carry 70%. Spend your time in proportion: the study weeks below follow this order.

Shares are DAMA's published Fundamentals weightings. Also learn the DAMA Wheel, the Environmental Factors Hexagon and the Context Diagram layout for each area: they sit behind questions in every section.

4 Six-week plan

Day 1 is Monday 3 November. Weeks 1 to 4 are study, week 5 is a buffer for revision, and you sit the exam in week 6 (8 to 14 December). The plan assumes about 12 hours a week: 1.5 hours on weekdays and 2 to 3 hours on each weekend day. Take the practice test once on day 1 as a baseline, then again at the end of weeks 2 and 4, and steer by your weakest areas.

4.1 Week 1 (3 to 9 Nov): Foundations, Governance, Modeling, Architecture (32% of marks)

• Day 1: Take the practice test cold (untimed is fine). Note your three weakest areas.
• Day 1: Read DMBOK2 Ch. 1 (Data Management): the DAMA Wheel, Hexagon, Context Diagram, DMBOK pyramid (Aiken), Strategic Alignment Model and Amsterdam Information Model.
• Day 2: Ch. 2 Data Handling Ethics: ethical principles, GDPR principles, risks of unethical practice.
• Days 2-3: Ch. 3 Data Governance: governance vs management, operating models (centralized, replicated, federated), councils, stewardship types, policies vs standards, change management.
• Days 4-5: Ch. 5 Data Modeling: conceptual, logical, physical; relational, dimensional, NoSQL; cardinality, normalization to 3NF, keys, entity types, notation (IE, Chen, Barker).
• Day 6: Ch. 4 Data Architecture: Zachman Framework rows and columns, enterprise data model, data flows, architecture vs design.
• Day 7: Make flashcards for every definition you missed this week. Ch. 15-17 skim: maturity models (CMMI levels), organization roles, change management.

4.2 Week 2 (10 to 16 Nov): Quality, Metadata, Master & Reference Data (32% of marks)

• Days 8-9: Ch. 13 Data Quality: dimensions (completeness, validity, accuracy, consistency, integrity, timeliness, uniqueness), Shewhart/Deming PDCA cycle, root cause analysis, cost of poor quality, profiling.
• Days 10-11: Ch. 12 Metadata: business, technical, operational metadata; metadata repository architectures (centralized, distributed, hybrid, bi-directional); lineage; ISO/IEC 11179.
• Days 12-13: Ch. 10 Master & Reference Data: MDM hub approaches (registry, transaction hub, consolidated), match and merge, golden record, survivorship, reference data sets and code lists, data sharing hubs.
• Day 14: Retake the practice test, timed at 90 minutes. Target 70%+. Redo every wrong answer against the DMBOK2 text.

4.3 Week 3 (17 to 23 Nov): DW/BI and Integration first (16% of marks), then the lighter areas (20%)

• Days 15-16 (priority): Ch. 11 DW & BI: Inmon vs Kimball, Corporate Information Factory, star and snowflake schemas, conformed dimensions, slowly changing dimensions (types 0-6), ODS, data marts.
• Day 17 (priority): Ch. 8 Data Integration: ETL vs ELT, latency (batch, CDC, near real time, synchronous vs asynchronous real time), hub-and-spoke vs point-to-point and the n(n-1)/2 interface count, canonical models.
• Day 18 (priority): Ch. 8 continued: publish and subscribe, enterprise service bus, SOA, data virtualization and federation, data sharing agreements, integration governance. Then review the Integration questions in the practice test and make flashcards for each miss.
• Day 19: Ch. 7 Data Security and Ch. 6 Storage & Operations, cheat-sheet depth only: the four As, confidentiality levels vs regulatory categories, masking; ACID vs BASE, CAP theorem, DBA roles.
• Day 20: Ch. 9 Document & Content and Ch. 14 Big Data, cheat-sheet depth only: GARP principles, records vs documents, EDRM; data lakes, schema-on-read, the Vs.
• Day 21: Flashcard review of your eight priority areas: Governance, Modeling, Quality, Metadata, Master & Reference Data, DW & BI, Architecture and Integration.

4.4 Week 4 (24 to 30 Nov): Close gaps and rehearse

• Days 22-24: Restudy your two lowest-scoring areas from the day 14 test. Write a one-page summary of each in your own words.
• Day 25: Practise searching the DMBOK2 PDF fast: find 10 terms in under 30 seconds each, and note the chapter page ranges.
• Day 26: Full timed practice test. Target 85%+.
• Day 27: Review every miss; reread the definitions and context diagrams for any area under 80%.
• Day 28: Light flashcards only, then rest.

4.5 Week 5 (1 to 7 Dec): Buffer and final revision

• Days 29-30: Restudy every area that scored under 85% in the day 26 test, using the DMBOK2 text, not the practice questions.
• Day 31: Flashcards across all 14 areas; reread the context diagrams for your eight priority areas.
• Day 32 (Thu 4 Dec): Final timed practice test. Judge by area scores, since you have now seen these questions before.
• Days 33-35: Close the last gaps, then reread the key concepts cheat sheet, key types and normalisation sections.

4.6 Week 6 (8 to 14 Dec): Exam week

• Confirm your exam date and time, and that your DMBOK2 PDF opens and searches quickly.
• Two days before: light review of the cheat sheet only, no new topics.
• Night before: check your exam setup (webcam, ID, quiet room) and rest.
• Exam day: follow the exam-day steps at the end of this guide.

5 Key concepts cheat sheet

These are the facts that most often decide a question. Learn the DMBOK2 wording, because the exam rewards its exact definitions over industry usage.

6 Key types

A key is one or more attributes that uniquely identify an entity instance; DMBOK sorts keys by how they are built (construction) and what they do (function). Every example below uses one small sales model: Customer, Order, Order Line and Product.

Running example. Customer has a system-generated Customer ID, a Customer Number printed on invoices (C-17), an Email that must be unique, and a Name. Order Line is identified by Order Number plus Line Number.

Each key type below uses the same small sales model. Cells shaded green are the key being described.

6.1 Candidate key

A minimal set of attributes that uniquely identifies each row. Remove any attribute and it stops being unique. An entity can have several.

Customer

Each shaded column is unique on its own, so each is a candidate key. Name is not: two different customers are both Asha Patel.

6.2 Primary key

The one candidate key chosen as the entity's identifier. It must be unique and never null.

Customer

Customer ID was chosen from the three candidates because it is short, stable and never changes.

6.3 Alternate key

A candidate key that was not chosen as the primary key. It is still unique, so it usually gets a unique constraint or index.

Customer

Customer Number and Email are the candidates left over after Customer ID became the primary key.

6.4 Super key

Any set of attributes that uniquely identifies a row, even if it includes attributes it does not need. Every candidate key is also a super key.

Customer

Customer Number + Name is unique, but Name adds nothing, so it is a super key and not a candidate key. Email + City and Customer ID + Email are other super keys.

6.5 Surrogate key

A unique identifier with no business meaning, usually a number the system generates. Users never see it.

Customer

90231 means nothing to the business. The database assigned it when the row was created.

6.6 Business key

One or more attributes the business itself uses to find a single instance. DMBOK treats business keys and surrogate keys as opposites.

Customer

Staff, invoices and phone calls use C-17 to find this customer.

6.7 Natural key

A widely used synonym for business key: an identifier that exists in the real world, outside the system.

Customer

An email address exists whether or not the customer is in our database. Other examples: ISBN, VAT number, vehicle registration.

6.8 Simple key

A key made of one attribute.

Customer

One column is enough to identify each row. Customer Number and Email are also simple keys.

6.9 Compound key

A key made of two or more attributes that only identify a row together.

Order Line

Order Number alone repeats (5001 twice) and Line Number alone repeats (1 twice), but the pair never does.

6.10 Composite key

In DMBOK terms, one compound key plus at least one other key or non-key attribute. The standard example is a fact table key.

Sales fact (star schema)

Date Key + Product Key + Store Key is a compound key of dimension foreign keys; adding Order Number (a degenerate dimension) makes the whole key composite.

6.11 Foreign key

An attribute in a child entity that holds the primary key of a parent entity. It creates the relationship and enforces referential integrity.

Order

Customer ID in Order points to Customer.Customer ID. It repeats (90231 twice) because one customer places many orders. It sits outside Order's primary key, so the relationship is non-identifying. In Order Line, Order Number is a foreign key inside the primary key, so that relationship is identifying.

6.12 Recap and exam traps

Try it yourself. A Staff table has Staff ID (auto-number), Payroll Number, Passport Number, Name and Department. Which are candidate keys, and which would you choose as primary? Candidates: Staff ID, Payroll Number, Passport Number. Choose Staff ID (surrogate); Payroll Number is the business key and an alternate key. Passport Number is a natural key but may be missing or change, so it makes a poor primary key.

How they nest: super keys contain candidate keys; one candidate becomes the primary key and the rest are alternate keys. A primary key can be simple or compound, and natural or surrogate.

Exam traps

• Compound vs composite: compound = several attributes forming one key; composite = a compound key combined with other keys or attributes. Most textbooks use the two words loosely, but DMBOK separates them.
• A surrogate key never replaces the business key. Keep the business key as an alternate key, or duplicates creep in.
• A foreign key can be part of the child's primary key (identifying relationship) or just a non-key attribute (non-identifying). See the next section.
• Foreign keys can be null when the relationship is optional.

7 Keys in relationships, star schemas and Data Vault

Where the foreign key lands decides the relationship type: inside the child's primary key makes it identifying, outside makes it non-identifying.

Star schema (dimensional model)

• Each dimension gets a surrogate key, often called the dimension key (Customer Key = 501).
• The source business key (Customer Number C-17) stays in the dimension as an ordinary attribute. With a Type 2 slowly changing dimension, one business key has several rows, each with its own surrogate key and effective dates.
• The fact table's key is a composite of foreign keys to each dimension (Date Key, Customer Key, Product Key), sometimes plus a degenerate dimension such as Order Number, which has no dimension table of its own.
• Dimensions are deliberately denormalised. A snowflake schema normalises them back into sub-dimension tables.

Data Vault

The exam point: hubs are built on business keys, links carry only keys, and satellites carry all the context and history.

8 Normalisation: one table, step by step

Normalisation applies rules so that each attribute depends on "the key, the whole key, and nothing but the key". DMBOK says third normal form is usually enough for a logical model, and it removes the redundancy behind update, insert and delete anomalies.

How to follow the steps. The same three orders, two customers and three products run through every step, using the same customers as the key types section. Every table is shown at every step, labelled new, changed or unchanged. Green columns are the primary key.

8.1 Step 0: Unnormalised form (UNF)

A shop keeps orders in one spreadsheet. The Items cell holds a repeating group.

Orders spreadsheet

Problem: you cannot query, total or validate a single item, and the table has no primary key that works.

8.2 Step 1: First normal form (1NF)

Split the repeating group into one row per order line, so every cell holds one value. No single column is unique now, so the primary key becomes the compound key Order Number + Product Code.

Orders (changed)

Anomalies still present:

• Update: the Notebook price is stored twice, so changing it in one row leaves the other wrong.
• Insert: a new product cannot be recorded until someone orders it, because Order Number is part of the key.
• Delete: deleting order 5003 also deletes the only record that a Stapler costs £7.50.

8.3 Step 2: Second normal form (2NF)

Check each non-key column against the whole key (Order Number + Product Code):

• Order Date, Customer Number, Customer Name and City depend on Order Number alone.
• Product Name and Unit Price depend on Product Code alone.
• Only Qty needs both.

Move each partial dependency into its own table. One table becomes three.

Order (new)

Product (new)

Order Line (new)

The Notebook price is now stored once. Order Line's key columns are also foreign keys to Order and Product, so both relationships are identifying. Tip: a 1NF table with a simple (one-column) primary key is automatically in 2NF.

8.4 Step 3: Third normal form (3NF)

Order still has a transitive dependency: Order Number → Customer Number → Customer Name, City. Asha Patel's details are stored on every order she places, so if she moves, many rows must change. Move the customer columns into a Customer table and keep Customer Number in Order as a foreign key.

Customer (new)

Order (changed)

Product (unchanged)

Order Line (unchanged)

Result: four tables, each fact stored once. Order to Customer is a non-identifying relationship, because Customer Number sits outside Order's key.

8.5 Step 4: Boyce-Codd normal form (BCNF)

The four 3NF tables are already in BCNF, because each table's only determinant is its primary key. BCNF only matters when a table has overlapping candidate keys, so the shop adds one more table to the same model: account managers.

Rules: each account manager looks after exactly one product, and each customer has one account manager per product. Key = Customer Number + Product Code.

Customer Product Manager (new)

This is in 3NF, because Product Code is part of a candidate key. It breaks BCNF, because Account Manager → Product Code and Account Manager is not a candidate key. If Dana Hill switches to Staplers (P-31), two rows must change. Decompose so every determinant is a key:

Account Manager (new)

Customer Manager (new)

Customer, Order, Product and Order Line stay as in step 3. Trade-off worth remembering: the rule "one account manager per customer per product" can no longer be enforced by a key alone. This is why designers sometimes stop at 3NF.

Quick way to test a table

1. Any cell with a list, or columns like Item1, Item2? Not 1NF.
2. Compound key, and a non-key column depends on only part of it? Not 2NF.
3. A non-key column depends on another non-key column? Not 3NF.
4. Any column (key or not) that determines another but is not a candidate key? Not BCNF.

9 4NF, 5NF and denormalisation

For the exam, know what 4NF and 5NF resolve and why denormalisation belongs in the physical model; you will not need to decompose a 5NF case by hand.

Fourth normal form (4NF) removes independent multi-valued facts held in one table. DMBOK describes it as resolving many-to-many-to-many relationships into pairs.

Example with the same products: the Notebook (P-10) comes from two suppliers and in two colours, and the two lists are unrelated. Holding both in one table forces every supplier to be paired with every colour.

Product Supplier Colour

Adding a Green notebook means adding two rows, one per supplier. Split it into two tables:

Product Supplier

Product Colour

Fifth normal form (5NF) splits a table into the smallest pairs that can be joined back without inventing false rows. DMBOK describes it as resolving inter-entity dependencies into basic pairs, where all join dependencies use parts of primary keys.

Example with the same products and the shop's two stores. Rule: if a supplier supplies a product, a store stocks that product, and the supplier delivers to that store, then the supplier supplies that product to that store. A three-column table repeats facts that three pair tables hold once each:

Supplier Product

Product Store

Supplier Store

Joining all three gives back exactly the original facts (PaperCo, P-10, Leeds; PaperCo, P-22, Leeds; NoteWorks, P-10, York) with no false rows.

Denormalisation is the deliberate move from a normalised logical model to physical tables with redundant or duplicated data. It is a physical design choice, not a logical modelling error.

Rule of thumb for the exam: normalise the logical model (to 3NF), and denormalise only in the physical model, for a stated reason, with a plan to control the redundancy.

9.1 Self-check

Cover the answers and test yourself. All questions are original practice items.

1. A table has primary key Employee ID, and also a unique National Insurance number. What is the National Insurance number? An alternate key (and a candidate key).
2. A table keyed on Flight No + Flight Date also stores Aircraft Type, which depends only on Flight No. Which form does it break? 2NF: a partial dependency.
3. Employee stores Dept No and Dept Name. Which form does it break? 3NF: Dept Name depends on Dept No, a non-key attribute.
4. Order Line's primary key includes Order Number. What kind of relationship links it to Order? Identifying; Order Line is a dependent entity.
5. In a star schema, what normally forms the fact table's key? A composite of the dimension foreign keys, sometimes with a degenerate dimension.
6. Which Data Vault table holds descriptive history? The satellite.
7. A key made of Store Key + Date Key + Product Key + Transaction No in a fact table: compound or composite in DMBOK terms? Composite.
8. Where does DMBOK say denormalisation belongs? In the physical data model.

10 Practice test and exam day

Use the CDMP practice exam on days 1, 14, 26 and 32. It has 100 original questions weighted like the real exam and scores you by knowledge area. Questions are written to DMBOK2 content and exam style; they are not real exam questions, which DAMA does not release.

• After each attempt, restudy every area marked Improve (under 70%) before any area marked Close (70-84%).
• Use study mode for your day 1 baseline if you want explanations as you go; use timed exam mode on days 14 and 26.
• Score 90%+ on a fresh attempt before you book or sit the real exam. Your memory of these questions will inflate later scores, so judge by the areas, not the total.

On exam day:

1. Answer every question; there is no penalty for guessing.
2. Do a first pass in about 60 minutes, flagging anything you would need to look up.
3. Use the remaining 30 minutes to search the DMBOK2 PDF for flagged items only.
4. Watch for words like NOT, BEST and PRIMARY; DMBOK2 answers favour governance, prevention and business-driven choices over technical fixes.