首先谈论一下服务器级别的两个对象，服务器登陆名和服务器角色。
服务器登陆名即登录服务器时所用的用户名，依靠这个服务器登陆名对象，数据库系统才能根据对象间的关系获取相应的数据库操作权限，因此可以把该对象看作权限树的根部和起点。SQL Server支持两种方式的登录：Windows身份认证和SQL Server身份认证。SQL Server2005默认的是Windows身份认证，集成Windows系统的验证模式，登录过程中登录名是确定的，不需要输入密码。SQL Server身份认证需要输入登陆名和相应密码，系统自动带有一个具有高级权限的登录名对象sa,其他对象可以通过TSQL语句创建。例如：create login Kelvin with Password = 'password' 执行后，数据库中即产生了名为Kelvin的服务器登录名对象。
上图中选中的为Windows身份方式登录的用户名，默认的登陆名一般是服务器名称。
服务器角色：SQL Server提供一组固定的服务器角色，比如sysadmin、securityadmin等，通过将这些固定的服务器角色赋予不同的服务器登陆名对象，可以是实现服务器级别的权限管理。将服务器角色赋予登陆名对象的语句如下： exec sp_addsrvrolemember Kelvin, sysadmin ; exec sp_dropsrvrolemember Kelvin, sysadmin; 一个服务器登录名对象可以拥有多个固定服务器角色权限，但是固定服务器角色不能被修改、添加和删除。
值得注意的是，服务器角色主要是控制服务器端对请求数据库资源的访问权限，他允许或拒绝服务器登陆名的访问操作，但是在设置具体数据库的管理和操作权限方面，服务器对象的权限设置粒度过大，因此要依靠数据库级别的对象：数据库用户（User）、数据角色（Role）、数据库架构（Schema），这三个对象是针对每一个数据库实例的，因此可以对单个数据库实例进行细化权限划分。
对于拥有服务器角色sysadmin的登陆名对象，它可以SQL Server2005中做任何操作（由此可见服务器角色权限粒度之大）。但对那些没有sysadmin角色的登陆名对象，它需要拥有一个能访问特定数据库实例的数据库用户名（User）以实现对该数据库的操作。比如说为登陆名Kelvin想要访问AdventureWorks数据库，但不具备sysadmin的服务器角色。那么则在AdventureWorks数据库中中创建一个名为user_Kelvin的数据库用户。TSQL：USE AdventureWorks; GO; create user user_Kelvin for login Kelvin; 执行之后，用Kelvin登陆名登录的用户与AdventureWorks下的user_Kelvin用户建立起了关联。
而数据库用户（User）的权限来源则是下面的两个对象：数据库角色（Role）和数据库架构（Schema）。通过在用户中选定相应的角色和架构，我们可以较为方便的实现数据库中数据的分离、存取权限的分离等权限管理。
数据库角色分为固定数据库角色和用户创建的数据库角色。固定数据库角色是系统默认用于组织数据库用户权限的角色，包括db_datareader、db_ddladmin、db_owner等，这些角色都包含与其名称相同的数据库架构（Schema），比如db_datareader就默认只拥有名为db_datareader的架构。用户可以创建角色，并让角色获取相应的架构，最后将角色（Role）与数据库用户（User）建立起联系即可。 比如： Use AdventureWorks; exec sp_addrolemember db_datareader, user_Kelvin; 执行后user_Kelvin就拥有了读取数据的权限（该权限为db_datareader角色拥有）。
数据库的架构应该是最小粒度的权限设置，既包括固定数据库角色对应的数据库架构，又可包括用户自身定义的架构。固定数据库角色对应架构主要涉及数据存取权限，比如db_datareader是允许读取该数据库中所有数据内容，db_datawriter即允许update、insert、delete语句等；用户自定义的架构主要用于分离数据，比如AdventureWorks数据库中拥有下列表：
对于只拥有Production架构的数据库用户来说，登录Adventure数据库只能看到前缀为Production.的表，其他前缀的表隶属于其他架构，对当前用户就不可见了（除非拥有其他架构）。
综上，服务器登陆名对象分别与服务器角色和数据库用户直接关联，而数据库用户与数据库角色和数据库架构直接联系，从而形成了整个数据库结构的权限管理。