...
From the data consumer’s perspective a materialized view would behave exactly like any other table or view in Synapse. For example, faceted navigation of materialized view would behave exactly like faceted navigation in a table.
The data consumer should not need to understand that the data in a materialized view was derived from one or more tables/views.
The data producer would be expected to construct materialized view on behalf of their data consumers.
The data producer would be expected to have a basic understanding of database normalization and the SQL join syntax.
When the source data of a materialized view changes (example a change occurs in the patients table), the materialized view should eventually get update automatically. Specifically, no users action should be required to force the materialized view to re-build upon source changes.
Materialized view sources can be either views, tables, or even other materialized views.
Materialized view are defined by SQL only. The SQL can include any supported SQL including joins, where clause, group by clause, and select functions.
All authorization checks on the source data must extends to materialized view.
Tables - If a materialized view has a source table, the The user must have the DOWNLOAD permission on the all source table to see any rows in the materialized view. All or none.
View - The user must have READ on each object from a view. Row level filtering.
...
A query against a materialized view is expected to return in under one second (on average). Queries against materialized views are expected to occur very frequently.
The time period between when the definition of a materialized view is created/update and when it is available for query can be unbounded. Materialized view changes are expected occur infrequently.
The time it takes to propagate source changes to materialized views can be unbounded. Such change propagation is expected to be eventually consistent. Source change propagation is expected to occur frequently.
Technical Requirements
...