In semantic data modelling there is layer called as Security Views and I was trying to understand how to apply Row level and Column level security in Security views.
Is this security means a user profile level which can be handled by DBA's OR something else which developer can handle it in views by writing some statements while developing views.
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.
The only topic I mentioned that is database version dependant is temporal features. They are in v12 and 13. The SMBB is not a database component. It is a design patern that we used to build several dimensional model products. See this discussion thread:
From your post what I understood is most of the security views (Row/Column) has been handled by DBA role activity.
Yes. The views are usually handled by the DBA. A skilled data modeler with a good tool can generate the "core" level view DDL. Perhaps a modeler could do even more, but that is not common in my experience.