数据仓库中有一个概念叫做Data Lineage，中文一般翻译为“数据世系”。数据世系描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。
数据世系信息需要留下详细的文档记载。数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。
数据世系是数据仓库的元数据中最重要的一部分。这部分元数据的产生位置是在ETL的处理过程中。
如果在ETL的处理过程中使用的ETL工具的话，ETL工具可以记录下元数据的一部分，但是这部分一般都是数据的属性描述，而不是完全的数据世系。换一句说，完全依靠ETL工具来维护元数据是不够的。
双桶连接－－double-barreled joins
退化维度――degenerate dimension
在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。
退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。
退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。
退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。
微型维度――minidimension
维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。
以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。
这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。
在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。
蜈蚣事实表――centipede fact table
在数据仓库领域有一个概念叫Centipede fact table，中文一般翻译为“蜈蚣事实表”。蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。
通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层的主键都放入事实表中，这样事实表中与产品相关的就会有产品ID、商标ID、子类ID、类别ID等多个外键。同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。这些都将产生蜈蚣事实表，使自己落入维度过多的陷阱。
蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。
一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现了维度过多的蜈蚣事实表。这时，需要做的事情是自己核查，将相关的维度进行合并，减少维度的个数。
稀疏事实表－－sparse facts
旋转事实表－－pivoted fact table