Skip to content

Rapid Recall Key 34–65

  1. Merge applies survivorship and can change the effective master view; reversal may require reconstructing prior identities, values, mappings, and history.
  2. Global ID = enterprise reconciled identifier; Source ID = local application identifier.
  3. X-Ref preserves mapping/history between Source IDs and Global ID, including merge/unmerge changes.
  4. One authorized generator protects enterprise uniqueness and prevents competing/colliding Global IDs.
  5. Affiliation = flexible typed association among entities; parent-child = direct hierarchical relationship.
  6. Sharing/Stewardship adds human accountability, exception handling, validation, feedback, maintenance, publication, and continuous improvement.
  7. Registry: enterprise identity/index points to Master Data still maintained in source SORs; minimal source disruption but distributed assembly can be complex.
  8. Transaction Hub: central hub owns updates and becomes SOR; applications maintain/access Master Data through it.
  9. Consolidated: source systems remain SORs while copies are reconciled into a central System of Reference; replication/latency are trade-offs.
  10. Registry points to distributed source-held data; Consolidated stores a shared integrated copy.
  11. Transaction Hub centralizes writes/SOR; Consolidated leaves writes in source SORs and centralizes a replicated consumer view.
  12. Six MDM activities: drivers/requirements; source assessment; architecture; Master model; stewardship/maintenance/DQ/matching controls; governance + share/maintain/monitor. Equivalent chapter-consistent wording earns credit.
  13. Six RDM activities: requirements/authoritative sets; source assessment; RDM architecture/acquisition; model code sets/mappings/hierarchies/Metadata; stewardship + controlled change/history; governance + publish/share/monitor.
  14. RDM architecture emphasizes update frequency/volatility, external/vendor delivery, history/versions, consumption, manual stewardship, approvals/notifications, mappings—and does not need entity-resolution machinery like MDM.
  15. Steward, source authority, update schedule/frequency, consumers, version/effective dates, history needs, definitions, mappings, status/deprecation.
  16. A central RDM repository creates value only when policy, integrations, stewardship, and consuming systems actually use its governed values.
  17. Specialized MDM applications, database/integration/DQ technology, workflow/stewardship tools, sharing hubs, and combinations of enterprise platforms; technology supports the discipline.
  18. Incremental implementation manages complexity, prioritizes business value, enables governance/process learning, and delivers under an enterprise roadmap rather than a big bang.
  19. Organization structure; number/distribution of SORs; governance maturity; latency/access needs; consumers; integration complexity; volumes/DQ; desired write authority; cost/source-change feasibility.
  20. Movement monitoring shows lineage, actual sharing/use, root-cause paths, ingestion/latency, and integration/transformation effectiveness.
  21. Request → stakeholders → impact → decide/approve → update → communicate/inform.
  22. Examples: add value; change value/description; deprecate/remove value; change mappings/cross-references; change hierarchy/structure/granularity or adopt new external version.
  23. Planned = expected/scheduled such as annual standard update; ad hoc = unplanned and needs case-specific impact/approval.
  24. Shared data, permitted uses, provider/consumer duties, privacy/security/retention, DQ/service expectations, issue/escalation, accountability for changes/failures.
  25. SLAs make availability/timeliness/service expectations explicit and measurable between provider and consumer.
  26. Departments can resist surrendering local definitions, identifiers, values, and process control to enterprise governance.
  27. Governance decides authoritative sources, stewardship, DQ/conditions of use, approval gates, sharing, privacy/security/retention, monitoring, exceptions, and escalation.
  28. DQ/compliance; change activity; ingestion/consumption; SLA/service; steward coverage; TCO; sharing volume/usage/adoption.
  29. Steward coverage identifies governed domains/data sets with or without accountable stewards and exposes ownership gaps.
  30. Change activity shows frequency/type/source/lineage of changes and can reveal instability, workload, risk, or tuning needs.
  31. Ingestion/consumption shows providers, consumers, volume/use, and whether the shared capability is actually adopted.
  32. Final model: govern classifications through RDM; reconcile entity identity through MDM; define authority/architecture; preserve quality, identifiers, mappings, history, reversibility; distribute via stewardship/sharing; measure and improve.

Source: Chapter 10, pp. 329–359.

← Key 01–33 · Blank-Page Rebuilds →