Business units need consolidated operational reporting without hammering the live OLTP permit system. Which pattern best fits that need?
Select an answer to reveal the explanation.
Short Explanation
Picture a busy kitchen pass and a plated-orders board out front. The ODS is that board: it gathers operational facts for looking things up and reporting without making cooks stop every time someone asks a question. OLTP keeps cooking; reporting reads the consolidated view.
Full Explanation
Consolidated operational reporting that must not hammer live OLTP fits an operational data store pattern: an ODS consolidates near-current operational data for reporting while insulating the transactional permit system. Nightly destruction of operational tables so reports run only on backups is not a sustainable reporting architecture. Embedding warehouse star schemas inside every transactional screen confuses analytic models with OLTP UX. Replacing all operational databases with a single uncontrolled data lake abandons transactional integrity. Exam pattern recognition: ODS for operational reporting insulation. Caveat: ODS freshness and reconciliation rules must be explicit so “near-current” is understood by municipal consumers. Operationally, route heavy operational reports to the ODS, verify OLTP CPU and locking improve, and document latency expectations so directors know how fresh the consolidated operational view is. Publish ODS freshness and reconciliation rules next to operational reports so directors know how near-current the consolidated permit view is. Monitor reconciliation breaks between ODS and OLTP permit totals and assign owners quickly so consolidated operational reporting does not silently diverge from the system of record.