分类帐纬度是一种方便直观的维度，可以将多个分类放入同一个事实表中，访问这一事实表的查询必须以单一值约束分类账维度（例如：最终使用的内部分类帐），否则查询将该表中的各种分类账计算两次，实施该模式的最好方法是为不同的用户提供不同的视图，试图中包含预先约束到单一值的分类账维度
设计者总是希望在事实表中存储“到目前为止”列，他们认为在每个事实行中存储“到目前为止季度”或“到目前为止年”等相加后的总计是比较有意义的，因为他们可以直接获得不需要计算。需要注意的是数字事实必须与粒度保持一致。“到目前为止”事实无法保持与粒度一致，因而非常容易产生错误，在以任意方式查询或汇总事实行时。这些不符合力度的事实产生荒谬的错误的结果。应该将他们从设计的模式中拿走，不要放在模式中。一般来说“到目前为止”总计应该通过计算获得，而不是存储在事实表中
在预算链中，日历层次是常见的深度固定的层次。每个层次都是具有实际意义的标记，从上卷角度来考察日历层次，其层次为天➡️财务周期➡️年，也可能是天➡️月➡️年度
账户维度也可以存在固定的多对一层次，例如总经理层、业务主管层和业务经理层账户。维度的粒度是业务经理层账户，但可以从最低粒度的细节账户上上卷到业务主管和总经理层次。在固定位置维度中，重要的是每个层次具有特定的名称，这样商业用户知道如何约束并解释每个层次
避免在固定位置层次中使用抽象的名称，例如级别一、级别二等等。这种方法虽然简单，但妨碍了对不整齐层次的正确建模。如果为级别定义了抽象的名称，则商业用户无法确定在何处放置约束，也无法知道级别中的属性值在报表中的含义。如果在固定位置层次中的不整齐层次以抽象名称定义，则单独的层次基本上没有意义
以共同粒度从多个组织业务过程合并度量的事实表被称为合并事实表。合并事实表时，它们必须具有同样等级的力度，因为不同的事实很少具有同样的力度，需要消除或聚集一些纬度以支持一对一对应关系，将原子数据保存在不同的事实表中，项目组不应该为试图适合合并不同粒度事实数据的需要而建立人工事实或维度
如果属性被分组，则业务代表需要在报表中见到适当的行标识值。属性名称必须具有实际意义
网友评论