一方面的“dbo”（用户）和“db_owner”（固定角色）的数据库概念与另一侧的“数据库所有者”的实例概念之间存在一些混淆。“dbo”和“db_owner”通常被称为“数据库所有者”。在您所问的内容中，您正在谈论数据库所有者作为拥有数据库的服务器主体。

理论是这样的：任何可以被授予权限的东西都是“安全的”。所有有价证券都有一个所有者。担保物的所有者对担保物拥有绝对的控制权，并且不能被剥夺任何特权。实例级安全对象由服务器主体（登录）拥有。数据库级安全对象由数据库主体（用户）拥有。主要有两种形式：主要（身份）和次要（成员）。默认情况下，服务器级别的安全对象归当前记录的主服务器主体所有。默认情况下，数据库级别的安全对象由当前数据库主体拥有，但默认情况下由架构所有者拥有的架构绑定对象除外。所有安全对象在创建时都支持 AUTHORIZATION 子句以强制执行不同的所有者。ALTER AUTHORIZATION以后可以用来更改任何安全对象的所有者。

由于数据库是服务器级别的安全数据库，因此默认情况下，它将由发出 CREATE DATABASE 语句的主要主体拥有。IE。离职员工的 NT 登录。

因此，您的问题实际上是“为什么安全对象需要所有者？ ”。因为所有者是信任的根源。授予、拒绝和撤销对象权限的是所有者。可以设计一个没有安全资产所有者的安全系统吗？可能是的，但必须有某种机制来取代当前模型中所有者所扮演的角色。例如，考虑爸爸安全对象没有所有者（例如，原始创建者只是被授予对它的控制权，而不是拥有安全对象），这将有可能创建一个安全对象并撤销对所有人的访问权限，包括他自己。业主的要求规避了这个问题，因为业主不能把自己锁在外面。

创建原始 NT 登录拥有的安全（数据库）的 CREATE DATABASE 的鲜为人知的副作用之前已经烧毁了很多。每个安全对象的规则都是相同的，但有些因素会加剧 DATABASE 所有者的问题：

• 其他服务器级别的安全对象（端点、服务器角色、登录）很少使用、移动等。
• 数据库级安全对象通常最终归dbo（数据库主体）或其他数据库主体所有，因此所有者包含在数据库中
• 将数据库所有权默认为 NT 主要主体会产生遏制问题（所有者是由 AD 管理的 NT SID，并且不与数据库文件一起旅行，NT 帐户可以是拇指石等）
• 最重要的事情：数据库所有者具有重要的副作用，特别是EXECUTE AS context. 后一个问题是大多数用户的痛点。由于 Service Broker 广泛使用 EXECUTE AS（消息传递具有隐式的 EXECUTE AS 上下文，以及具有显式上下文的队列激活），通常是 Service Broker 用户首先发现此问题。