Most database administrators understand the concept of row‑level security. Returning to the payroll data example, all detailed compensation data on the employees of an organization is stored in the same table(s) within the database. Typically, some column within this table can be used as a limit, either directly or by a join to another table with its own set of limits, to restrict access to the data within the table based on the identification of the user accessing the data. Following the payroll example, an employee ID often identifies the sensitive compensation data. A join to a separate employee information table, which contains non-compensation related information such as home address and title, would include a department number. A manager would be limited to details on the employees for her/his particular department.
Row‑level security, implemented at the database level, is often done by means of a view. To an application, accessing a view is no different than accessing a table. However, the view is instantiated based on the appropriate limits. Coupled with the GRANT and corresponding REVOKE data definition statements available with the prevalent Relational Database Management Systems (RDBMS), the base tables can be made inaccessible to most users, and the views on that data, filtered based on user identification, made accessible instead. Multiple views may sometimes be required to fully implement a security scheme, depending on how the tables are defined and how the information contained therein must be shared. For instance, a different view for managers versus those in human resources might be required.
Column level security, a companion concept to row‑level security, can be similarly enforced. Views can easily hide a piece of information. For example, in the payroll example, the salary column can be left out of the view, but other types of information about an employee can still be accessible to those who need it. This type of security can impart a special problem for standardized reports, available throughout the organization but for audiences with different access permissions. The reporting software might have difficulty dealing with the missing information, consequently requiring different implementations of these otherwise similar reports.