当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETL Toolkit中有详细的描述。使用代理关键字是一个从长远考虑的策略。
多值维度――multivalue dimension
在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。
多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。
多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。
处理多值维度最好的办法是降低事实表的粒度。如第二种情况中，将健康护理单分列项事实表的粒度降低到具体的诊断粒度上，这样就避免了多值维度的出现。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。
但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与顾客维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个帐户-顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。
非事实型事实表――factless fact table
在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。
第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。
合并事实表－－consolidated/ merged fact table
在数据仓库领域有一个概念叫merged fact table，或者consolidated fact table，中文一般都翻译为“合并事实表”。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法，合并的事实要保证在相同的粒度。
这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术，可以避免性能较差的交叉探察操作。
但是，这种合并事实表和使用交叉探察操作还有着细微的不同，在一些基础表中没有记录的时候，合并事实表中可能会存储一条记录，字段值保存为零。
合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数据也给用户带来了很大的方便。但是，合并事实表给ETL工作带来了较大的麻烦。对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致性维度。
缓慢变化维――slowly changing dimension