Control of access to sensitive data is a fundamental part of TDV. Row-Based security is a form of access control that can be applied to specific rows. Row-Based security prohibits access to restricted rows. Typically, row-based security is controlled by defining different data viewing permissions based on user and group.

TDV has a guided method to help you create a row filter policy that is based on user or group. TDV also provides access to the SQL script that drives the row filter policy. You can create and modify the associated SQL script files to define a custom row filter policy. For example, the salaries for employees or the locations of specific assets, might be data that you want to keep restricted from certain groups or users. Or, you could restrict access based on time of day or region.

If you are using row-based security policies in combination with column-based security policies, TDV applies the row-based policy before applying the column-based policy.

A row filter policy is a SQL script that is used to define how you want the data access controlled. The two major row filter policy categories in TDV are:

Regardless of your row filter policy definition, the table or view that it is assigned to will never provide more data than it would without the row filter policy applied to it.

If you are defining tabular row filter policies, you can use TDV to define multiple rules. Each tabular row filter policy can contain one or more rules. Each rule is associated with a specific user or group that is defined within TDV. When defining rules, you can choose:

Assignments are used to associate particular row filter policies to a table or view resource. A single row filter policy can be applied to one or more tables or views. After row filter policies are defined and applied to resources, data viewing can be controlled based on the criteria of the row filter policy.

The row filter policy that you define does not alter the SQL code of your view or table. The row filter policy only temporarily adds to the WHERE clause of SQL statements that consume the table or view.

Row filter policies are added at run time using the AND operator. Rules defined are added together at runtime using an OR operator.

You can define row filter policies and apply them to views that are part of your TDV data caching environment. However, if a view definition uses the results of a table or view that has a row filter policy assigned to it, the cache cannot be created.

Within Studio, if you have views with a row filter policy and caching enabled and you open the cache associated with that view, you can see all the data in the view as if the row filter policy had not been applied. For example, if you have a row filter policy and cache defined on ORDERS, when you view data for ORDERS you will see the data as constrained by your row filter policy. However, if you view the data for ORDERS_CACHE, you will see all the data.

Because it is possible to define individual row filter policies and group row filter policies and assign them to the same resources, you could run into some behavior that might not seem predictable.

In the case of 2 policies assigned to specific resources that are also used in a group and assigned to the same resources, TDV would apply the policies using an algorithm like, (p1 and p2) or (p1 and p2).

To add a further example, given the V_SALES view with region, product and customer data and polices set up for REGION, PRODUCT, and CUSTOMER with filters in each to segment each data set based on ID. For V_SALES, if a group row filter policy is created that combines each policy into one and then assign the group to it.

If the ALL selection is chosen, the three policies are combined in the SQL with AND operators.

If the ANY selection is chosen, the three policies are combined in the SQL with OR operators.

For more information on how to define groups, see Creating or Editing a Row Filter Policy Group.