事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表，注意OLAP的lookup table主要是指数据的基础维度以及一些衍生维度；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。使用维度表有诸多好处，具体如下。
·缩小了事实表的大小。
·便于维度的管理和维护，增加、删除和修改维度的属性，不必对事实表的大量记录进行改动。
·维度表可以为多个事实表重用，以减少重复工作。
多维分析模型
星型模型
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
雪花模型
雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2，将地域维表又分解为国家，省份，城市等维表。其实就是把一张事实表拆成多张小维度表，并通过key关键。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
区别
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。目前kylin只支持星型模型，或者通过ETL工具建星型模型转换成一张宽表再进行多维分析。。
cube 介绍
cube的设计是olap系统的核心，这会影响到查询分析的覆盖程度和性能。如果cube设计的维度太多，那么会导致构建速度很慢，存储空间浪费，查询性能低的现象。所以在满足需求的条件下，对cube不断的优化。
针对N维的数据分析而言，一共可以衍生出2n中聚合结果，如图所示，4个维度的排列组合。用数学的公式来说就是 C40+ C41 + C42 + C43 + C44。一个星型模型的维度数量最好控制在15以内，由于cube构建数量和维度是指数关系，所以维度太高会导致cube构建时间很长，并且，数据量的增大也会导致查询速度下降。如果真的有这么多的维度需要分析，那么可以拆成多个星型模型。
kylin维度组合模式 概述
cube的维度很容易爆炸，因为是指数增长的，所以降维是cube设计中的核心，下面是kylin支持的几种cube组合模式。
Normal
正常模式。也就是N个维度构建成2N个cube。
例子：假设有三个维度A,B,C每个维度都为Normal模式，那么构建的cube如图2，cube的总数为C30+C31+C32+C33。
图2
Mandatory维度强制模式。当某个维度设置为Mandatory模式，那么该维度会出现在所有cube的构建中，比如时间维度，可以强绑定到cube的构建中。这种构建模式可以很大程度降低最后生成的cube数量，但是会导致分析失去一定的灵活性。
例子：假设有三个维度A,B,C 其中维度A为Mandatory模式，那么构建的cube如图3，最终生成的cube数为C20+C21+C22
图3
Hierarchy