ROW LEVEL SECURITY There are various ways through which the row level security can be implemented

i n a Business Objects environment. One way is by securing the datamart. In case of this approach, the datamart is s ecured meaning the security policies and rules are written in the datamart. Tech nically, a security table can be created and maintained having the users / group s with corresponding access rights. Security policies can have a logic to compa re the active logged in user and security table. All the users accessing the dat amart are provided access to their data only after executing the security polici es. We can also embed the security policies and rules in a view. A good example for row level security is Non-Managers cannot see the data of co-workers howev er managers can see the data of his / her sub-ordinates. In Oracle (for example) , we can create a non-manager and manager views with the security rule (<securit y_table.user> = USER ). The security views are imported in the Business Objects ( B O) universe and the reports use these security views through the universe. The m ain ADVANTAGE of securing your datamart is that your security rules can also be used by many other BI tools ( Cognos, Microstrategy ) as the rules are built at the datamart and NOT at the Business Objects) Second way is by building the security rules at the Business Objects. Here the s ecurity rules comparing the logged in user and security data can be written in a virtual table of your Business Objects. These virtual tables are nothing but th e universe derived table. BO Reports use the derived table to access the datamar t tables. Alternatively, we can also define security filters in a BO universe. T he filters are called as condition / filter objects in the BO universe world. W ith this approach, you can take the maximum ADVANTAGE of the BO features however the disadvantage is that when you are going to a different BI tool like Cognos you need to rewrite the business security rules in your new tool. In case of the projects dealing with the migration of Peoplesoft transactional r eporting to Business Objects analytical reporting. We can potentially reuse / im port some security tables and security policies from Peoplesoft into our analyt ical datamart. These reusable components can save time in building the secured d atamart and reporting environment. COLUMN LEVEL SECURITY Like Row level security , we can implement the column level security either at the datamart or Business Objects. In the financial industry, the business users do n ot want their revenue amounts, social security number , tax id number and other sensitive columns to be shown to unauthorized users. Given this instance, we ca n mask the sensitive columns by a restricted tag in the place of sensitive colum ns. Non-sensitive columns like first name , last name , gender , age can be left and shown as it is to the end business user. These logic can be technically imp lemented in the business objects universe derived table or datamart views using a decode / if then else / case statements.