（续前文：小数据：理论和架构）
从前文的架构图中可以看到，针对“小数据”的OLAP应用可以分为三个环节：
- Cube建模。将数据从OLTP数据库中抽取到OLAP Cube中。
- 分析。针对OLAP Cube进行切片、钻取等操作，获得需要的结果集。
- 呈现。将结果集呈现为直观的报表形式。
在建模Cube的时候，需要用户提供的信息是Cube本身星型结构的描述，以及星型结构中各项信息与OLTP数据库中表和字段的映射关系。具体而言，这里必需的信息包括：
- Cube的标识符
- Cube对哪些数据项量值（measure）
- 如果涉及聚合值(aggregate)，采用何种算法聚合
- Cube有哪些维度（dimension）
- 其中某些维度可能有层级（hierarchy）关系
- Cube的量值项和维度项如何与OLTP数据库中的表和字段映射（mapping）
- 其中通常会涉及多表的关联（join）
由于分析操作仅以RESTful API的形式提供服务，因此用户在进行分析操作时需要提供的信息就是一个URL，在其中描述分析操作的详情，包括下列信息：
- 对哪个Cube进行分析
- 呈现所有事实（fact）还是聚合（aggregate）结果
- 对哪些维度进行切片(cut)
- 对哪些维度进行下钻（drilldown）
从分析环节得到的数据应该是一张平面的二维表（flat table）或与之等价的其它形式（例如JSON）。在报表呈现环节，用户就只需要描述如何将二维表渲染成报表。必需的信息大致包括：
- 采用何种报表形式（折线图、柱状图、饼图……）
- 如何使用二维表中的各列数据，以柱状图为例：
- 使用哪一列作为横坐标的取值
- 使用哪一列作为纵坐标的取值
- 使用哪一列分组或堆叠
- 如果允许下钻，使用哪一列（或几列）下钻
以上列表未必完备，但已经能覆盖大多数小数据场景的OLAP需求。不论采用何种技术实现，小数据分析系统应该尽力约束用户（不论开发者还是最终用户）需要输入的信息量，尽量使其只需输入（不论通过编程还是图形界面操作）上述列表中的必需信息项，从而降低系统建设和使用的难度。
