What it shows:
A structured map of data entities, their specific attributes (e.g., Project_ID, Permission_Level), and the precise rules/cardinality governing their relationships (e.g., “One Project contains Many Elements”). It represents the data requirements logically, without dictating the physical database technology.
Why it’s needed:
Configuration mapping and security enforcement. This proves to InfoSec and Governance teams that a structural plan for data security exists. It visually demonstrates how a user’s security profile logically connects to the data they are allowed to see, which is the foundation for configuring Role-Based Access Control (RBAC).
When to use it:
Highly recommended for Custom Development and complex integrations. For COTS deployments, it is highly recommended if the project requires the configuration of complex security metadata, custom RBAC groups, or designing APIs to extract specific data attributes into other systems. While the database itself is not being built, the logical data rules the platform should enforce are being designed.
When NOT to use it:
Generally best to omit for “out-of-the-box” COTS deployments where no custom metadata or complex RBAC is being configured, or for pure infrastructure hardware projects (e.g., upgrading storage arrays, routing switches). If the system doesn’t require the configuration of internal data relationships, this diagram is unnecessary.
Example:
