在SQL Server 中，角色是一个新概念。使用数据库角色有什么意义呢？
我们新增了7个固定的服务器角色和9个固定的数据库角色。服务器角色是分散系统管理员工作的一个办法。在SQL Server 6.5和更早的版本中，有一个叫做“sa”的帐号，这个帐号可以在数据库服务器上做任何事情。在那时，你可以有10个Windows NT用户被映射成“sa”，这意味着这10个用户都可以在任何时间做任何事情，然而服务器审计工具只会记录成“sa”的操作。你没有任何办法来确认到底是谁做了什么操作。
SQL Server 7.0改进了这一点。不是像以前那样使“sa”具有所有的特权，权限是通过角色成员来获得的。我们还把系统管理员的特权划分成了多个角色。例如，为了在SQL Server 7.0中让某人获得系统管理员权限，你只需要把他加入到“sysadmin”这个固定服务器角色中即可。
还有其它角色，例如“dbcreator”是用来创建和更改数据库的；“securityadmin”是用来增加新的登录或者重置缺省数据库的。“sa”登录仍然存在，是为了保持向后兼容性。 但该权限是通过成为“sysadmin”角色中的成员来获得的。服务器的审计追踪功能将根据你的Windows NT或者SQL Server登录名来跟踪所做的改变，而不管分配给该帐号的安全特权。
在单个数据库这一级别上情况也非常相似。在以前版本中，人们会把自己化名为“dbo”来获得对数据库的所有权限。现在用户可以被分配成“db_owner”角色，同样可以拥有对单个数据库的完全控制权限。而且，还有更具体的角色，比如“db_acessadmin”用来控制对数据库的访问，“db_securityadmin”用来给予其他用户访问权限，“db_backupoperator”用于备份数据。我们还增加了用户自定义的和应用程序角色，而且允许用户可以同时成为多个数据库角色的成员。
应用程序角色是如何工作的？
可能解释应用程序角色的最好方式是在实际情况中说明。比方说你想做一个职工工资单的应用程序，可以允许用户更新工资。当然你不希望允许用户简单地登录到SQL Server中然后更改工资。如果雇员能够那样做的话，他就可能试图去更改他自己的工资了。更合适的方法是使用一个工资单应用程序，它能够执行特定的安全检查，例如，不允许用户更新他们自己的工资。
它是这样工作的。你的工资单应用程序以使用者的安全级别登录到SQL Server，以便服务器审计追踪工具能够知道到底是谁在登录到SQL Server。然后你的应用程序切换到适当的数据库并调用系统存储过程“sp_setapprole”来启动应用程序角色。应用程序角色是受密码保护的，所以你需要把密码作为参数传递给sp_setapprole。当数据在网上传输时，你也可以对密码进行加密。
一旦启动了应用程序角色，用户现有的权限被关闭，应用程序角色的安全权限被相应打开。你的应用程序现在就可以使用应用程序角色来执行修改数据库的操作了。
需要注意的一个问题是，应用程序角色是特定于连接的。假如你同时打开了两个到SQL Server的连接，你必须保证每个连接的应用程序角色都被打开了。使用应用程序角色时，一旦打开连接并转换到适当的数据库后，第一件事情就是调用“sp_setapprole”存储过程。如果不启动应用程序角色，你就不能够访问任何应用程序角色所专有的数据。
