In order to give the members of the AMERICAS group access to sales information only for the appropriate region, the query includes references to columns in other tables which are not necessarily part of the existing data model. The row‑level security will function the same whether or not the tables already existed in the data model.
As seen in the table relationships pictured above, the region information is bridged to the sales information by the store table. To implement a constraint that makes only sales information available for a particular region requires two entries in the BRIOSECR table, one to join sales to stores, and one to join stores to regions. This latter case also requires a limit value for the region name. (A limit on REGION_ID could also accomplish the same goal, but is not as readable, especially in an example. See the discussion to follow about subqueries for another perspective on limits on ID type columns.)
The first restriction required for this example is on the STORE_ID column. In order to use that column, a join must be made back to the STORES table. Figure 13, Join to STORES Table shows how this join would be specified.
Now, the join to the Regions table is added, with the appropriate constraining value, as shown in Figure 14, Join to Regions Table.
The only remaining part of the example is letting user BRIO, also a member of the AMERICAS group, see the data in an unrestricted way. Handling this case is left as an exercise for the reader.