Security views in Semantic data modelling. - response (2) by HC-LDM

In the "pyramid" analogy for semantic layer design, traditional Teradata methodology proposes a layer for security views.  The following comments are based on typical needs and not any specific scenario.  Row level security is provided via the security layer views.  Column level security is provided by a "privacy view" layer just above the security layer.  Specifically, the security layer is a set of database views that:
-provide views of a table that receive database permissions to control who may access the table data, preferably specified by database role
-may filter values to provide row level security
-hide columns that exist for ETL or temporal purposes
-use the same column names as the table
-The security layer does not perform joins to present information from multiple tables
The privacy layer may:
-vertically partition security layer views to provide column level security
-facilitate decryption on specific columns that were encrypted at the table level
Row and column level security may be enforced by assigning appropriate database roles to specific database user profiles to leverage the security layer. 
The security layer is preceded by a layer of access granted only to DBAs and often referred to as "one to one" or "1:1" or "core" views.  This is the layer closest to the tables.
Teradata semantic level design methodology is evolving for purposes of dimensional (star schema) access.  This is reflected in our line of Semantic Layer Building Block (SMBB) products.  SMBB products provide a select set of dimensions overlaid on our industry data models using view layers.