第二步：材料成本引用视图“物料清单”。

　　由于视图“材料成本”此时还需要用到基础表“物料清单”中的内容，此时，数据库就会先去查询“物料清单”的所有者。由于此时所有者跟其调用者“材料成本”不是同一个所有者，故数据库会继续去查询“物料清单”这个视图的相关访问权限。若用户Lance有这张表的访问权限，则数据库就会返回相关的内容。相反，若用户没有这张表的查询权限的话，则数据库就会拒绝用户的请求。虽然其有前面两个数据库对象的访问权限。在数据库的“链”中，当调用对象的所有者不同的话，我们就叫做“所有权链条断裂”。

　　第三步：跨数据库的连接。

　　SQL Server数据库服务器允许在同一台服务器中部署多个数据库。故从事软件租赁的企业，往往一个数据库管理员需要同时管理多个公司的数据库。此时，为了管理方便，他们往往会启用“跨数据库的链接”。若启用了这个功能，则这个所有权链的权利寻租问题也会发生在不同的数据库之间。

　　如上图，现在A公司的数据库有张视图“产品成本”，所有者是Landy。而在B公司的数据库中也有张视图“产品成本”，所有者也是Landy 。如果现在用户Landy把A公司数据库中的视图“产品成本”访问权限赋予给了用户Lance，由于两张视图的所有者相同，若A公司数据库中的“产品成本”根B公司数据库中的“ 产品成本”存在调用关系的话，则因为两者的所有者一样，所以A公司用户Lance同时具有B公司数据库中“产品成本”的访问权限。

　　二、权利寻租中的安全隐患。

　　所有权链确实给数据库管理员带来了很大的方便。如果“链条”中的各个数据库对象其所有者相同，则用户就可以在单个对象上进行相关的权限设置，就可以实现对多个对象的访问权限控制。

　　但是，这个所有权链仍然存在一些安全隐患，主要涉及到以下两个方面。

　　一是跨越数据库的欺骗访问。假设现在B公司的数据库有一张视图“产品成本”，这个对象的所有者为“Landy”。此时，若A公司的数据库管理员Lance想要非法访问B公司数据库中的“产品成本”这个对象，该如何处理呢？凭借SQL Server的数据库链条，可以很方便的实现这个非法的目的。如数据库管理员Lance在A公司数据库中建立一个用户Landy，并以这个用户的名义建议一个数据库对象，如一张视图。然后让这张视图去调用B公司数据库中的“产品成本”对象。此时，由于这两个数据库对象形成了一个“链条”，其权限控制原则就是按照“所有权”链的原则来处理。由于这两个数据库对象的所有者类似，则用户Lance就具有B公司数据库“产品成本”的访问权了。同理，利用这个原理，A公司的数据库管理员可以拥有B公司数据库中所有对象的访问权限。

　　这个现象对于大部分企业来说，都是不想看到的。为了解决这一安全隐患，最简单的方法就是不要启用“跨越数据库所有权链”。默认情况下，这是不启用的。可是在实际工作中，数据库管理员为了日常管理的方便，往往会把它开启。此时，数据库管理员就需要在安全与便利上取得一个均衡。

　　第二个安全隐患是权限的自动赋予。如上面这个例子中，当用户把所有权链中第一个对象“产品成本”的访问权限赋予给Lance后，就意味着用户Landy把这个链条中所有对象的访问权限，如视图或者基础表，赋予给了这个用户。这虽然对数据库管理员来说，大大方便了其管理。但是，却降低了数据库的安全性。

　　在上面这个例子中，其链条之涉及到三个数据库对象。而在一些中大型的数据库应用中，一个链条锁涉及到的数据库对象往往多达几十个。此时，在采用所有权链的过程中，就需要特别的小心。

　　笔者以前在数据库设计中，就因为考虑的不够全面，而给用户过多的权利。如用户Lance其虽然具有“产品成本”视图的访问权限。也就是说，用户可以知道某个产品的总成本信息。但是，其不需要知道这个产品的成本构成，不需要知道这个产品材料成本是多少，制造费用是多少。但是，由于这个用户有材料成本的访问权限(通过所有权链的权利寻租实现)，就留下了一定的安全隐患。若这个用户稍微懂一点数据库技术，则就可以通过一定的手段获取这个保密的信息。

　　所以，在数据库设计中，所有权链是假定对象所有者能够预见到授予对象权限的每个决定的全部后果。但是，这在中大型数据库的设计过程中，往往是不现实的。人的思维毕竟没有计算机那么严密。

　　为了解决这个安全隐患，笔者的做法是把基础表跟其他对象，如视图，设置为不同的所有者。如此的话，所有权链中对象的权限，就有两个控制的关卡。除了在所有权链条中的第一个对象进行控制之外，还可以在基础表的级别上加一把锁，以实现信息的安全性。