A city IT lead claims every table in the permitting database is master data because staff reuse those tables often. Which distinction should the information manager make?
Select an answer to reveal the explanation.
Short Explanation
Think of master data as the cast of regulars on a municipal stage—residents, parcels, contractors—not every ticket sold at the door. Permit transactions pile up fast and change constantly; parties, assets, and locations are the shared cores everyone points to. Reusing a table a lot does not make it master data.
Full Explanation
An information manager should distinguish master data as the relatively stable shared core entities—such as party, asset, and location—that many civic processes reuse, not as every frequently accessed table in the permitting database. High-volume transactional permit rows are activity facts; reusing them operationally does not convert them into master entities. Claiming any table with more than one foreign key is automatically master data fails because referential structure alone does not define shared, slowly changing core identity. Asserting master data only exist in a warehouse and never in operational databases fails because operational systems routinely hold party and location masters that MDM must govern. Declaring every report column master data because analytics consumers share it fails by confusing shared reporting attributes with master-domain entities. Exam caveat: master data ≠ “tables people reuse a lot”; focus on stable shared core entities versus transactions. Operational check: inventory candidate domains (party, location, asset), separate transactional permit facts, and confirm stewardship and match scope apply only to true master entities before funding an MDM tool. Document the distinction in the municipal data architecture note so permitting teams stop labeling every busy table as master data.