基于之前的讨论，我们会收集派生过程中涉及的维度字段，大多数来讲这些字段都存在于业务过程中作为一种行为属性，但是有些情况，业务限定与业务过程无关，比如新老用户，这种情况我们一般通过建设用户user_id的dim维表，然后关联dim表和dws表计算ads的报表，这是我们已知的。
但是我们仔细分析这里面的计算过程，举一个场景，报表要计算优质和普通用户的商品浏览数。按照之前的设计dws方式，因为业务限定中存在”user_id是否优质用户”，于是最细粒度dws表就包含了user_id粒度，然而这是多余的，或许这个dws表不用cuid这么细的粒度，可以把区分优质用户的dim表加入到dws表计算中，比如：
insert overwrite table dws_view_bhv_1d
select goods_id, is_levelA, count(1) as pv
from tieba_dwd_view_1d
where user_id in
(select user_id, is_levelA from dim_user_level group by user_id, is_levelA)
groupby goods_id, is_levelA
以goods_id, is_levelA为统计粒度的dws表完全满足我们的需求，user_id就可以去掉。
那么我们是如何做出这样的判断呢，因为该主题域下所有的派生过程中除去该业务限定”user_id是否优质用户” 外，不包含user_id这个粒度；反过来想，如果包含的话，那么这一步的处理就是没有必要了，依然按照dim表和dws表计算得到ads的报表。
当然上述过程也可以通过将是否优质用户加入浏览行为dwd表中，这样该业务限定就是”user_level = A”，但这样带来的问题就是dwd表包含了与业务过程无关的属性，导致了业务不合理之处。
再举一个实际发生的情况，用户发表文章曝光时效性报表，该报表有一个统计粒度是曝光时间和文章发布时间的间隔分层（0-6h, 6-12h），按照我们的方法几乎是不能构建这样的dws表，不可能按照曝光时间optime去汇总dws表，但是可以按照上面方法将这部分处理放在dws表的构建中完成，最后生成时间间隔分层的统计粒度。
我们进一步思考上面这几个例子，业务限定即是对某个维度的业务取值做限定，限定可能发生在事实表内（用户浏览商品的页面位置），也可以在事实表外（关联维度表，是否优质用户）。规范化上述过程，业务限定可以表达为，其中v是某个事实表维度，发生在事实表内即
，发生在事实表外即
对应维度表中维度实体与维度属性的函数关系。而一般地，我们是把
放到dws表维度组合中，其实也可以考虑用
代替
作为dws表的一个维度，这也是上面讨论的内容。
在我们应用实践中，还经常发现这样的业务限定，把是否活跃用户，是否VIP用户，是否老用户三个限定一起分析，而分析中的取值并没有8个之多，可能就有2，3个。那么我们就可以生成一个新的维度，表示用户优质等级，然后把这样的属性作为dws汇总的一个维度，这样就可以极大地减少汇总表的基数值。这也是数仓维度建模中的杂项维度概念的应用。
通过对业务限定的抽象化，我们发现一些隐藏于派生过程的维度表，而某一个维度属性与维度实体在我们的数仓中应该有且只有一个函数关系，否则说明数据建设过程中存在歧义的地方，这些歧义之处本质上是不同的函数关系。
