External auditors want to understand, at a glance, how the tables in a payment system relate to one another, including which tables reference which and with what cardinality. Which design document is best suited to communicate this?
Select an answer to reveal the explanation.
Short Explanation
When you need to show relationships, draw a picture. An ERD is the family tree of your tables, with lines and crow's feet saying who's related to whom and how many. The data dictionary is great for column details, but it's a list, not a map.
Full Explanation
An entity relationship diagram presents entities or tables as boxes and relationships as connecting lines, with notation such as crow's foot to show cardinality and optionality. It lets a reader see quickly which tables reference which, through primary and foreign keys, and whether relationships are one-to-one, one-to-many or many-to-many. That visual summary is exactly what auditors need to understand how payment data flows between tables. A data dictionary is the complementary text reference: it describes each column's type, meaning and allowed values and may note foreign keys, but as a list it does not convey the overall structure at a glance. A query execution plan shows how the optimizer will run one statement, which is useful for tuning but unrelated to documenting the schema. An SLA performance report records measured service metrics such as availability against targets and contains no information about table relationships. Exam caveat: ERDs exist at logical and physical levels; for auditors a logical diagram with clear names is usually more readable than one cluttered with storage detail. Operational check: generate or update the ERD from the current schema, confirm every foreign key in the database appears on the diagram, and record the diagram's version alongside the schema version.