You can use stored procedures and functions for instance. Tracking who-saw-what can be done through specially developed stored procedures and functions. In order to use this auditing method, access to the database must be limited through use of stored procedures (allowing EXEC statements only, while prohibiting all queries and DML operations). The result from a query is returned by a stored procedure, while at the same time the stored procedure logs the access in an appropriate auditing repository table along with additional information of interest (e.g. the time of the execution)
However, this auditing method requires T-SQL programming and additional maintaining of the stored procedures and functions (e.g. in case of the database schema change). Moreover, ad hoc queries executed by trusted parties (e.g. members of the sysadmin role) easily override the rule that SELECT statements must be parsed by a stored procedure, and therefore cannot be tracked
Beside traces, you can also use the SQL Server Audit feature, introduced in SQL Server 2008. The feature utilizes the Extended Events technology, and audits both server and database events. However, auditing on database level is supported by the Enterprise and Developer editions only
Using SQL Server Audit as the method for tracking execution of SELECT statements produces less overhead than the trace technology, but depending on how busy the database is, an impact on server performance might occur. Either T-SQL or SQL Server Management Studio options can be used to set up the SQL Server Audit feature