...
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 - The user must have the DOWNLOAD permission on the all source table tables referenced in the view to see any rows in the materialized view. The user must also meet all AccessRequirements on all tables referenced in the view 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.
...