Master Data, Metadata, and Data Curation

Key Takeaways

  • Domain 6 (~9%) includes Competencies 6.3–6.5: master data consistency, glossary maintenance, security awareness, KPI validation, data curation (catalog + internal dashboards), and metadata distinctions among master, operational, and transactional data.
  • Competency 6.3.1 requires consistent representation of enterprise entities (keys, attributes, hierarchies); 6.3.2 is Practical Knowledge—follow rules to maintain the business glossary rather than invent private definitions.
  • Master data is relatively stable shared reference data; transactional data records events; operational data supports day-to-day process state—confusing these layers drives bad joins and wrong metrics (6.5.1).
  • Data curation (6.4) catalogs assets and builds internal analytics dashboards as governed products tied to definitions, lineage, freshness, and access controls—not one-off chart dumps.
  • Strong MDM, metadata, and curation prevent many Domain 2 failures: duplicate keys, orphan joins, conflicting attributes, unknown better datasets, and invalid KPIs.
Last updated: July 2026

Master Data, Metadata, and Data Curation

Quick Answer: CBDA Competencies 6.3–6.5 (Domain 6, ~9% of the exam) expect business data analytics practitioners to ensure consistent representation of enterprise data (master data management), maintain business glossaries, distinguish master vs operational/transactional data, apply metadata and privacy awareness, and curate assets—cataloging what exists and supporting internal dashboards. Strong MDM and metadata reduce the join failures, duplicate keys, and definition fights that Domain 2 quality work keeps rediscovering.

Domain 6 asks you to guide organization-level strategy for business analytics—not only to complete one project well. Master data management (MDM), metadata, and data curation are the enterprise backbone that makes every research question, source plan, and dashboard more trustworthy and cheaper to produce. On scenario items, expect stems about inconsistent customer IDs across systems, teams inventing competing definitions of “active customer,” or a request to “just pull everything” without knowing which assets already exist. The high-scoring path usually prioritizes shared definitions, consistent keys, catalog discovery, and governed reuse—not heroic one-off cleanses that disappear when the analyst leaves.

Why MDM Matters for CBDA Practitioners

Master data is the relatively stable, shared reference data that describes who, what, and where the business cares about across processes: customers, products, employees, locations, suppliers, accounts, and similar entities. Master data management is the set of people, processes, and technology practices that keep those entities represented consistently—one agreed identity and set of attributes, synchronized or reconciled across systems of record.

Competency 6.3.1 is stated as general awareness / basic knowledge: ensure that data is represented consistently. You are not expected to implement an enterprise MDM platform alone. You are expected to:

  • Recognize when analytic failures are really identity and definition failures
  • Prefer shared master keys and attributes over local copies reinvented per report
  • Escalate material master-data defects to data owners/stewards rather than silently “fixing” them only inside one spreadsheet
  • Connect MDM outcomes to metrics/KPI validity (Competency 6.3.4): if “customer” is defined differently in finance and marketing, KPI validation will fail no matter how elegant the model

Consistent representation in practice (6.3.1)

Consistent representation means that the same real-world entity maps to the same logical identity and that critical attributes (status, hierarchy, geographic region, product family) do not contradict each other across the systems you integrate for analysis.

Failure modeAnalytic symptomMDM-oriented response
Multiple customer IDs for one personInflated unique-customer counts; broken cohort analysisGolden-record / match-merge rules; survivorship policy
Product codes differ by channelMargin by SKU disagrees with financeCanonical product hierarchy; mapping tables with owners
Location or org unit renames without historyTrend breaks at cutover datesSlowly changing dimensions + effective dating
Status values mean different thingsFunnel metrics cannot reconcileControlled vocabularies in the glossary

Exam trap: Choosing “run a more sophisticated algorithm” when the stem clearly shows duplicate master keys or conflicting entity definitions. Better answer: improve consistency of representation (keys, match rules, glossary, stewardship), then re-analyze.

Glossary Maintenance (6.3.2 — Practical Knowledge)

Competency 6.3.2 is one of the few Domain 6 items labeled Practical Knowledge: Follows Rules—you contribute to maintenance of a glossary under established rules, not invent free-form jargon.

A business glossary (sometimes paired with a data dictionary) holds agreed business terms, definitions, owners, related metrics, and often links to technical fields. Glossary work is not clerical busywork; it is how the organization prevents semantic drift—two teams using the same word for different populations or formulas.

What “follows rules” looks like for BAs

  1. Use the official term when a glossary entry exists—do not invent a parallel label in a deck or dashboard title.
  2. Propose updates through the process when analysis exposes a gap (missing term, ambiguous definition, conflicting usage)—attach evidence (which reports disagree, which decision is blocked).
  3. Link terms to metrics/KPIs so validation (6.3.4) has a single definition to test against.
  4. Respect ownership: business stewards own meaning; technical stewards own field mappings; you facilitate alignment, not unilaterally redefine finance terms.
  5. Version and communicate: when a definition changes, note effective date and impact on historical comparability.

CBDA scenario pattern: Marketing defines “churn” as no login in 30 days; Finance defines it as cancelled subscription. The glossary either has one authoritative definition for a named metric or two named terms (e.g., engagement dormancy vs subscription cancellation) with explicit formulas. The wrong move is averaging the two numbers or hiding the conflict.

Master vs Operational and Transactional Data (6.5.1)

Competency 6.5.1 requires basic knowledge of the differences between master data and operational and transactional data. Exam stems often test whether you pick the right layer for a problem—or wrongly treat high-volume transactions as the source of truth for entity identity.

Data typeWhat it isExamplesChange patternAnalytics role
Master dataShared reference entities and their core attributesCustomer, product, employee, siteRelatively stable; careful change controlJoin keys, dimensions, segmentation bases
Transactional dataRecords of business eventsOrders, claims, payments, ticketsHigh volume; append-heavyFacts, measures, event timelines
Operational dataData supporting day-to-day process execution (often system-specific, including status and workflow state)Work-queue state, inventory positions, case assignmentsFrequent updates; system-of-record specificProcess performance, operational dashboards

Key distinctions for exam answers:

  • Identity lives in master data. You do not invent a new “customer” from each order line without a master key strategy.
  • Measures usually come from transactions (revenue, count of claims) sliced by master dimensions (product family, region).
  • Operational snapshots can be correct for “as of now” process management but poor for longitudinal analysis if history is overwritten—pair them with event history or carefully designed snapshots.
  • Quality approaches differ: master data emphasizes uniqueness, match quality, and hierarchy integrity; transactional data emphasizes completeness of events, late-arriving facts, and referential integrity to master keys.

When Domain 2 join/linkage failures appear (orphan foreign keys, many-to-many surprises, duplicate parents), the root cause is frequently weak master data—not “SQL skill.”

Metadata Management Concepts

Metadata is data about data: definitions, lineage, owners, sensitivity labels, refresh schedules, grain, allowed values, quality scores, and usage context. Metadata management makes assets findable, interpretable, and trustworthy.

For CBDA, think in three practical layers:

  1. Business metadata — glossary terms, metric formulas, business owners, intended use and limitations
  2. Technical metadata — schemas, data types, primary/foreign keys, partition schemes, pipeline names
  3. Operational metadata — last refresh time, row counts, job success/failure, data quality scores, SLA status

Why metadata shows up on the exam

  • Without lineage, you cannot defend a KPI or explain a sudden break (Competency 6.3.4 validation fails).
  • Without sensitivity labels, privacy rules (Competency 6.5.2) cannot be applied consistently.
  • Without grain and definition metadata, two dashboards with the same title will disagree.
  • Without ownership metadata, curation and stewardship stall—nobody knows who can approve a definition change.

Privacy note (6.5.2): Basic knowledge of identifying and applying data privacy rules sits with metadata (classification: PII, PHI, restricted) and with access patterns on curated assets. Curated catalogs that expose unrestricted downloads of sensitive master attributes create compliance risk even if “the dashboard is internal.”

You also connect to 6.3.3 (basic knowledge of data security): consistent representation includes who may see master attributes, not only how they are spelled. Security and privacy are adjacent to MDM; they are not optional afterthoughts when you publish an enterprise customer list for “self-service analytics.”

Data Curation: Catalog Assets and Internal Dashboards (6.4)

Competency 6.4 is Perform Data Curation:

  • 6.4.1 Understands building internal reporting/analytics dashboards
  • 6.4.2 Understands scanning and cataloging the data assets in a company

Data curation is the ongoing discipline of selecting, organizing, documenting, quality-checking, and presenting data assets so others can use them responsibly. It is the organizational alternative to every analyst hunting through shared drives and shadow databases.

Cataloging data assets (6.4.2)

A data catalog inventories datasets (tables, files, APIs, marts, feature stores) with metadata: description, owner, domain, freshness, quality indicators, related glossary terms, and access path. Scanning can be automated (schema crawlers) plus human enrichment (business descriptions, certified flags).

BA contribution to cataloging:

  • Map research-question domains to known assets before requesting new collection (ties to Domain 2 sourcing)
  • Flag certified vs experimental assets so decision-makers do not treat sandbox extracts as official
  • Document known limitations (sample bias, excluded regions, delayed finance close)
  • Promote reuse of curated marts instead of proliferating one-off extracts

Internal dashboards (6.4.1)

Internal analytics dashboards are curated products, not screenshots. Curation implies:

  • Metrics tied to glossary definitions and validated against source (6.3.4)
  • Clear audience and decision use (ops vs executive vs compliance)
  • Documented refresh cadence and known data latency
  • Access control aligned with privacy/security
  • Feedback loops: when users question a number, route to definition/lineage—not ad hoc “fix the chart”

Exam trap: Treating curation as “pretty visualization only.” Visualization is Domain 4 packaging skill; curation is the organizational asset layer that makes those packages sustainable and comparable.

How MDM Reduces Join and Quality Failures from Domain 2

Domain 2 (Source Data, ~15%) is where practitioners feel pain: completeness, consistency, uniqueness, timeliness, validity, accuracy, join integrity, outliers, and linkage quality. Many of those defects are symptoms; MDM and metadata often address the systemic cause.

Domain 2 symptomLikely enterprise rootMDM / metadata / curation lever
Duplicate customer rows after multi-source joinNo golden record / match policyMDM match-merge; uniqueness rules on master keys
Orphan foreign keys (orders without customers)Transaction systems allow free-text or local IDsReferential integrity to master; cleansing + source controls
Conflicting attribute values across systemsMultiple systems of record, no survivorshipSurvivorship rules; single source of truth for attributes
“Complete” fields that are wrongValid format, wrong entityAccuracy via master validation, not only validity rules
Teams redefine metrics each quarterNo glossary / no certified martGlossary + curated KPI layer + validation (6.3.2, 6.3.4, 6.4)
Late discovery that a better dataset already existsNo catalogAsset scanning and catalog (6.4.2)
Join multiplies rows (fan-out)Ambiguous grain or hierarchyDocumented grain metadata; master hierarchies with correct cardinality

Worked mini-scenario

A BA is asked why regional sales dashboards disagree by 8–12%. Investigation shows:

  1. Region is assigned from shipping address in one system and billing address in another (master attribute inconsistency).
  2. “Active customer” includes prospects in marketing’s extract but only paid accounts in finance (glossary gap).
  3. Product returns are excluded in one pipeline and netted in another (transaction grain + no shared metric definition).
  4. A certified enterprise mart already exists but was unknown to the project team (catalog failure).

The Domain 6 response is not “pick the highest number.” It is: align master region attribute and survivorship, publish glossary entries for active customer and net sales, validate KPIs against the certified mart, and register the mart in the catalog so the next team does not rebuild the conflict.

Security and KPI validation as MDM companions

  • 6.3.3 Data security: Consistent master data often concentrates sensitive identifiers—apply least privilege, masking, and access reviews when curating enterprise entities.
  • 6.3.4 Metric/KPI validation: Validation is only possible when the metric’s population, formula, time window, and source are defined (glossary + metadata) and when master dimensions used as breakdowns are stable. MDM without KPI validation still produces pretty wrong charts; KPI validation without MDM still joins garbage.

BA Role Boundaries

CBDA practitioners contribute to MDM, glossary, metadata, and curation. They typically do not single-handedly own enterprise data platforms. On the exam, prefer answers that:

  • Partner with data owners, stewards, architects, and governance forums
  • Document definitions and limitations for decision use
  • Use and improve shared assets rather than create permanent shadow datasets
  • Escalate material integrity risks before high-stakes decisions

Study Checklist for This Section

  • Define master data and state Competency 6.3.1 (consistent representation)
  • Describe Practical Knowledge 6.3.2 glossary maintenance behaviors
  • Contrast master vs operational vs transactional data (6.5.1) with examples
  • Explain business, technical, and operational metadata and why lineage matters
  • Link privacy (6.5.2) and security (6.3.3) to curated master assets
  • Describe data curation: cataloging (6.4.2) and internal dashboards (6.4.1)
  • Map Domain 2 join/quality failures to MDM/metadata root causes
  • Recall that KPI validation (6.3.4) depends on shared definitions and trustworthy masters
Test Your Knowledge

A CBDA practitioner finds that three regional dashboards report different unique customer counts because CRM, e-commerce, and billing each store separate customer IDs for the same people. Which Domain 6 response BEST addresses the root cause?

A
B
C
D
Test Your Knowledge

Competency 6.3.2 (glossary maintenance) is labeled Practical Knowledge: Follows Rules. Which action BEST demonstrates that proficiency level?

A
B
C
D
Test Your Knowledge

Which statement BEST distinguishes master data from transactional data for Competency 6.5.1?

A
B
C
D