A 311 dashboard must join service requests to neighborhoods for reporting without exposing raw PII columns to analysts. What programmability object should the team create?
Select an answer to reveal the explanation.
Short Explanation
A view is the 311 dashboard’s frosted glass—analysts see neighborhood request patterns without staring at raw resident PII underneath. You shape the civic report once and keep the sensitive columns out of the projection.
Full Explanation
311 dashboards often need neighborhood-level request patterns without exposing resident PII to analysts. A view can join service requests to neighborhood reference data while projecting only non-sensitive columns, giving a stable reporting shape that omits raw personal fields. Programmability via views is the straightforward Azure SQL pattern for shaping and restricting what dashboard users SELECT. A trigger that emails every PII column to a distribution list increases exposure rather than reducing it. A SEQUENCE that replaces neighborhood names with random integers destroys geographic meaning needed for neighborhood reporting. An in-memory OLTP table that duplicates all PII multiplies sensitive copies and does not by itself create a safe projection for analysts. Caveat: views are not a full security boundary unless permissions are locked down (and, where required, combined with other controls); revoke SELECT on base tables that contain PII and grant access only through the view. Operational check: SELECT from the view as a dashboard role and confirm neighborhood metrics appear while PII columns from the base request table are absent and unauthorized direct SELECTs on base PII fail.