用户帐户可标识与数据库的连接。 对用户帐户授予和拒绝的数据库和数据集权限将确定用户可以访问的内容。 可以根据所需执行的任务对用户帐户进行分组，从而简化权限的管理。
用户帐户
用户帐户是用来标识连接到数据库的人员或客户端应用程序的唯一名称和密码。 在 ArcGIS 中，用户帐户将确定何人有何数据。 用户帐户还提供了一种控制个人或客户端应用程序对数据库或地理数据库及其数据集拥有何种访问权限（如果有）的方法。
请注意，您可以在 ArcGIS 外部创建包含特殊字符的用户名，但是使用时，必须将这些用户名用分隔符分隔开来。 当用户名传递到 SQL Server 时，ArcGIS 会自动为其添加分隔符；您无需在登录时添加分隔符。 例如，如果您的用户名是 map.user，则从 ArcGIS 登录到 SQL Server 时输入 map.user，而不是 "map.user"。 有关常规标识符和分隔标识符的详细信息，请参阅 SQL Server 文档。
数据所有权
对于 ArcGIS 而言，在地理数据库或数据库中创建表、要素类和视图的用户拥有这些数据集。 例如，地理数据库由地理数据库管理员创建；那么，当时在数据库中创建的地理数据库系统表归此地理数据库管理员所有。 同理，创建某个要素类的用户即是该要素类的所有者。
创建数据集时，用于与地理数据库建立连接的用户名是数据集的所有者。
拥有数据的用户同样必须在数据库中具有名称与用户名相同的方案。
例如，兼职员工 Boris 和 Basil 均获准在地理数据库中创建数据集。 Boris 和 Basil 使用的是同一台计算机。 如果两人均在 ArcGIS 中使用 Basil 的帐户连接到地理数据库，则由 Boris 或 Basil 创建的所有数据集都归 Basil 所有并存储在他的方案中。
如果 Boris 要将他创建的数据存储在自己的方案中，则在创建数据之前，必须更改数据库连接属性，然后使用自己的用户名连接到数据库。
了解数据归谁所有至关重要，因为如果某用户在数据库中拥有数据，则不允许将该用户帐户从数据库中移除；而且，将由创建数据集的用户控制其他用户访问该数据集的权限级别。
用户访问
数据库必须能够验证尝试连接该数据库的用户帐户。 这意味着数据库管理员必须将用户添加到数据库中。 然后，数据库可通过查看用户列表确定用户是否有权建立连接。 此过程称为身份验证。
身份验证类型将有所不同，具体取决于您是连接到 SQL Server，还是受支持的基于 SQL Server 的数据库服务之一。 有关身份验证的详细信息，请参阅 ArcGIS Pro 中的数据库连接。
添加完用户后，数据库管理人员必须为用户授予特定权限，以确定他们在数据库中可执行或不可执行的操作。 经过验证的用户试图访问或更改数据库时，数据库将针对这些权限进行检查。 此过程称为授权。 在 ArcGIS 中，数据所有者还可以将数据的权限授予给其他用户或组。
为用户授予的权限类型取决于用户需要执行的作业类型。 一些用户只需要连接到数据库并查看特定数据。 而其他用户需要创建新的数据集。 以下部分介绍如何对用户帐户进行分组以简化权限管理。
组或角色
大多数数据库管理系统都会根据用户对数据访问的需求，为数据库管理员提供多种将用户分组和将权限分配到组的方法。 这样就可以减少更改每个用户权限所花费的时间，并简化大量用户的大量权限管理。 因此，可以根据用户的常用功能，使用组（也称为角色、类型或者基于数据库管理系统的机构）来授予用户权限。
常用用户类别或群组为数据查看者、数据编辑者和数据创建者。
大多数情况下，在企业级地理数据库中，为组授予权限并不妨碍为单个用户授予权限。 例如，可将在数据库中创建数据所需的最低权限授予给数据创建者组（该组也可能包括地理数据库管理员），然后将其他权限仅授予给地理数据库管理员用户。 每个数据库管理系统处理权限的优先级都不同，因此，有关角色和单个用户的权限行为的详细信息，请参阅数据库管理文档。
此外，许多数据库管理系统提供了预定义组。 其中一种预定义组为 PUBLIC 角色。
PUBLIC 组或角色基本上是一个同等对待所有连接到该数据库的用户的变量，因此，授予给 PUBLIC 的权限也授予给了每个连接到数据库的用户。 但在某些情况下，所有用户都需要一个特定的权限。 例如，若要连接到 SQL Server 或 Db2 数据库，用户必须具有连接权限。 由于所有用户都需要具有该权限才能进行连接，因此 SQL Server 和 Db2 默认将此权限授予 PUBLIC。
有时，在创建数据库时，会默认为 PUBLIC 授予高级别权限。 然而，出于安全原因，仅应在绝对必要时才为 PUBLIC 授予权限。
有关其他预定义组，请参阅数据库管理系统文档。
有关将用户进行分组的提示
以下是关于在数据库管理系统中对用户进行分组的几点提示：
- 为系统和对象权限创建独立的组（角色）。 这样，数据库管理员便可通过向系统组授予数据库权限来管理数据库权限，数据所有者便可通过向对象组授予数据集权限来授予这些权限。
- 为了便于参考，选择一个反映各类组（角色）的命名约定。 例如，对于能够编辑所有土地基础数据的组，可以将其命名为 LANDBASE_EDITORS。
- 直接将权限授予给地理数据库管理员，然后通过组（角色）为所有其他用户授予权限。 地理数据库管理员是一个唯一实体。 在大多数情况下，对于任何地理数据库，都只存在一个这样的用户，并且它不属于一个较大逻辑用户组。 经验丰富的数据库管理员会认为这是良好的设计，可以直接向这类应用程序管理员帐户授予权限。 与之相比，非管理员的帐户应通过表示其作业描述的组、项目职责或组织内的其他逻辑分类来获得权限。
- 避免非管理员帐户的角色与直接授予的权限发生混淆。 当非管理员帐户通过角色获得权限并直接授予其帐户权限时，一个精心设计的安全模型可能会迅速转变成一种难于管理的混乱状态，这需要相当长的时间和努力才能恢复到一个有秩序的状态。 为数据所有者设置策略，在授予其数据访问权限时需要遵守。
在极少数情况下，非管理员帐户才具有真正唯一的安全性要求，此时可考虑直接授予某些权限以避免使基于角色的安全模型复杂化。 将这些情况存档；它们应当只是极个别的情况。