在商业数据处理的早期阶段，写人数据库通常对应于商业交易场景，例如销售、订单、支付员工工资等。尽管后来数据库扩展到了不涉及金钱交易的领域，事务一词仍然存在，主要指组成一个逻辑单元的一组读写操作。

事务不一定具有ACID（原子性、一致性、隔离性和持久性）属性。事务处理只是意味着运行客户端进行低延迟读取和写入，相比与周期性运行的批处理作业。

尽管数据库开始被用于眸多不同种类的数据，例如博客的评论、游戏中的动作、通讯录中的联系人等，然而其基本访问模式仍然与处理业务交易类似。应用程序通常使用索引中的某些键查找少量记录。根据用户的输入插入或更新记录。因为这些应用程序是交互式的，所以访问模式被称为在线事务处理（ online transaction processing,OLTP ）。

数据库也开始越来越多地用于数据分析，数据分析具有非常不同的访问模式。通常，分析查询需要扫描大量记录，每个记录只读取少数几列，并计算汇总统计信息（如计数、求和或平均值），而不是返回原始数据给用户.

为了区分使用数据库与事务处理的模式，称之为在线分析处理（online analyticprocessing , OLAP)

相同的数据库可以同时用于事务处理和分析查询。在这方面， SQL被证明是非常灵活的，可以同时胜任OLTP类型和OLAP类型查询.在20世纪80年代后期和90年代初期的一种趋势是，公司放弃使用OLTP系统用于分析目的，而是在单独的数据库上运行分析。这个单独的数据库被称为数据仓库。

数据仓库包含公司所有各种OLTP系统的只读副本。从OLTP数据库（使用周期性数据转储或连续更新流）中提取数据，转换为分析友好的模式，执行必要的清理，然后加载到数据仓库中。将数据导入数据仓库的过程称为提取－转换－加载(Extract-Transform-Load,ETL ）.

几乎所有的大型企业都有数据仓库，但是在小型企业中却几乎闻所未闻。这可能是因为大多数小公司没有那么多不同的OLTP系统，大多数小公司只拥有少量的数据，完全可以在传统的SQL数据库中直接进行查询分析，甚至可以在电子表格中进行分析.

有许多图形化数据分析工具，它们可以生成SQL查询、可视化结果并支持分析师探索数据，例如通过诸如向下钻取、切片和切丁等操作。

一些数据库（MicrosoftSQLServer和SAP HANA ）在同一产品中支持事务处理和数据仓库.还出现了大量开源的基于Hadoop的SQL项 目，它们还比较年轻，但都试图与商业数据仓库系统展开竞争。 包括Apache Hive 、 Spark SQL 、 Cloudera Impala 、 Facebook Presto 、 Apache Tajo和Apache Dril l [52 '531 。其 中一些系统是基于Google Dremel而构建的.

事务处理领域广泛使用了多种不同数据模型。而另一方面，分析型业务的数据模型则要少得多。许多数据仓库都相当公式化的使用了星型模式，也称为维度建模.==一个事实表连很多维度表

图3-9所示的模式可用于零售数据仓库。模式的中心是一个所谓的事实表（在这个例子中，它被称为fact sales）。事实表的每一行表示在特定时间发生的事件（这里，每一行代表客户购买的一个产品）。如果我们正在分析网站流量而不是零售，则每一行可能表示页面视图或用户的单击。事实表存放如客户购买了一个商品这个行为，表中有购买时间id、客户id、产品id、数量、门店id、成本价、销售价、仓库。每个id都是一个维度表用于存放该对象的属性。

名称“星型模式”来源于当表关系可视化时，事实表位于中间，被一系列维度表包围；这些表的连接就像星星的光芒。

该模板的一个变体称为雪花模式，其中维度进一步细分为子空间。例如，品牌和产品类别可能有单独的表格，在dim_product表中的每一行都可以再次引用品牌和类别作为外键，而不是将其作为字符串直接存储在dim_product表中。雪花模式比星型模式更规范化，但是星型模式通常是首边，主要是因为对于分析人员，星型模式使用起来更简单。如产品表存放了品牌id和类别id，这些id就可以对应一个新的维度表。

在典型的数据仓库中，表通常非常宽：事实表通常超过 100列，有时候有几百列［51 ］。维度表也可能非常宽，可能包括与分析相关的所有元数据，