在本节中，将主要关注事实表的存储。虽然事实表通常超过100列，但典型的数据仓库查询往往一次只访问其中的4或5个。
在大多数OLTP数据库中，存储以面向行的方式布局：来自表的一行的所有值彼此相邻存储。文档数据库也是似，整个文档通常被存储为一个连续的字节序列。
面向列存储的想怯很简单：不要将一行中的所有值存储在一起，而是将每列中的所有值存储在一起。如果每个列存储在一个单独的文件中，查询只需要读取和解析在该查询中使用的那些列，这可以节省大量的工作。
面向列的存储布局依赖一组列文件，每个文件以相同顺序保存着数据行。因此，如果需要重新组装整行，可以从每个单独的列文件中获取第23个条目，并将它们放在一起构成表的第23行。
除了仅从磁盘中加载查询所需的列之外，还可以通过压缩数据来进一步降低对磁盘吞吐量的要求。幸运的是，面向列的存储恰好非常适合压缩。
看看图3-10 中每列的值序列：它们看起来有很多重复，这是压缩的好兆头。取决于列中具体数据模式，可以采用不同的压缩技术。在数据仓库中特别有效的一种技术是位图编码。
数据仓库的另一个值得一捷的是物化聚合。如前所述，数据仓库查询通常涉及聚合函数，例如SQL中的COUNT 、 SUM 、 AVG 、 MIN或MAX。如果许多不同查询使用相同的聚合，每次都处理原始数据将非常浪费。为什么不缓存查询最常使用的一些计数或总和呢？
创建这种缓存的一种方式是物化视图。在关系数据模型中，它通常被定义为标准（虚拟）视图：一个类似表的对象，其内容是一些查询的结果。不同的是，物化视图是查询结果的实际副本，并被写到磁盘，而虚拟视图只是用于编写查询的快捷方式。从虚拟视图中读取时·， SQL引擎将其动态地扩展到视图的底层查询，然后处理扩展查询。
当底层数据发生变化时，物化视图也需要随之更新，因为它是数据的非规范化副本。数据库可以自动执行，但这种更新方式会影响数据写入性能，这就是为什么在OLTP数据库中不经常使用物化视图的原因。
物化视图常见的一种特殊情况称为数据立方体或OLAP立方体［64］。它是由不同维度分组的聚合网格。