早期，数据库写入通常对应于一个商业交易：比如销售，订单等。虽然随着数据库演变成一个不涉及货币的领域，事务/交易（transaction）这个词一直被保留事务，是指由一组读写操作组成的逻辑单元。事务不一定具有ACID。事务处理只是意味着允许客户端执行低延迟读写，而不是只能定期运行（例如，每天一次）的批处理作业。尽管数据库开始用于许多不同类型的数据，例如博客评论、游戏操作、地址簿联系人等，但基本访问模式仍然类似于处理业务事务。应用程序通常使用索引通过一些K来查找少量记录。根据用户输入添加或更新记录。由于这些应用程序是交互式的，因此这种访问模式称为联机事务处理（OLTP，OnLineTransactionProcessing）。但是数据库也越来越多地用于数据分析，并且它们具有非常不同的访问模式。通常，分析查询会扫描大量记录，只读取每条记录的几列，并计算摘要统计信息（例如计数、总和或平均值），而不是将原始数据返回给用户。例如，如果数据是销售交易表，则分析查询可能包括：一月份每家商店的总收入？在最近的促销活动中多卖了多少根香蕉？哪个品牌的婴儿食品最常与品牌X尿布一起购买？这些查询通常由业务分析师编写，并输入报告中以帮助公司管理层做出更好的决策（商业智能）。为了将这种使用数据库的模式与事务处理区分开来，称为联机分析处理（OLAP，OnLineAnalyticsProcessing）。表1：事务处理与分析系统最初，同一个数据库用于事务处理和分析查询。SQL已被证明在这方面非常灵活：它可以处理OLTP和OLAP类型的查询。但在80年代末和90年代初，公司放弃了使用OLTP系统进行分析，而是在单独的数据库（数据仓库）上运行分析。一个数据仓库企业可能有几十个不同的交易处理系统：面向最终客户的网站、控制实体店的收银系统、仓库库存跟踪、车辆路线规划、供应链管理、劳动力管理等等。这些系统中的每一个都很复杂，需要专门的维护，因此系统最终彼此独立运行。这些OLTP系统通常对业务运营至关重要，因此在处理事务时通常需要高可用性和低延迟。因此DBA密切关注他们的OLTP数据库，并且DBA通常不愿意让业务分析师在OLTP数据库上运行临时分析查询，因为这些查询通常很昂贵并且扫描大型数据集，这会损害并发执行事务的性能。相比之下，数据仓库是一个独立的数据库，分析师可以在不影响OLTP操作的情况下查询他们想要的内容。数据仓库包含公司各种OLTP系统的只读副本。数据从OLTP数据库中提取（使用定期数据转储或连续更新流），转换为适合分析的模式，清理并加载到数据仓库中。在仓库中存储数据的过程称为“Extract-Transform-Load(ETL)”：图8：数据仓库和简化的ETL过程大工厂几乎都有数据仓库，但小工厂很少听说。可能是因为小厂没有那么多不同的OLTP系统，一般只有少量的数据，可以直接在传统的SQL数据库中查询分析，甚至可以用Excel分析。在大厂做一件在小厂很简单的事情，往往需要做很多繁重的工作。使用单独的数据仓库而不是直接查询OLTP系统进行分析的优点之一是可以针对分析访问模式优化数据仓库。前面讨论的索引算法适用于OLTP，但不擅长处理分析查询。OLTP数据库V.S数据仓库DataWarehouse的数据模型通常是关系型的，因为SQL通常非常适合分析查询。有许多GUI数据分析工具可以生成SQL查询、可视化结果并允许分析师探索数据（通过向下钻取、切片和切块等）。从表面上看，数据仓库类似于关系型OLTP数据库，因为它们都有SQL查询接口。但是这些系统在内部非常不同，每个系统都针对非常不同的查询模式进行了优化。许多数据库供应商专注于支持事务或分析工作负载，而不是两者。某些数据库，例如MicrosoftSQLServer和SAPHANA，在同一产品中支持事务处理和数据仓库。但它们正日益成为两个独立的存储和查询引擎，恰好可以通过一个通用的SQL接口进行访问。最近出现了一大批基于Hadoop的开源SQL项目。尽管它们还很年轻，但它们正在与商业数据仓库系统竞争。进入ApacheHive、SparkSQL、ClouderaImpala、FacebookPresto。星型和雪花型分析模式根据应用程序的需要，在事务处理域中使用各种不同的数据模型。用于分析业务的数据模型要少得多。许多数据仓库以一种相当公式化的方式使用，称为星型模式（也称为维度建模）。图9中的模式显示了可能在食品零售商处找到的垃圾箱。模式的中心是一个事实表（在本例中称为fact_sales）。事实表的每一行代表在特定时间发生的事件（这里每一行代表客户购买的产品）。如果分析网站流量而不是零售销售，每一行可能代表用户的页面浏览量或点击率：图9：数据仓库的星型模式示例**一般事实被捕获为单个事件，因为这样可以在您的分析。但是，这意味着事实表可能很大。像Apple这样的巨头可能在数据仓库中有几十PB的交易历史记录，其中大部分存储在事实表中。事实表中的列是属性，例如产品的销售价格和从供应商处购买的成本（可以计算利润率），其他列是对其他表的外键引用（称为维度表）。由于事实表中的每一行都代表一个事件，因此这些维度代表事件发生的地点、时间、方式和原因。如图9所示，其中一个维度是销售的产品。dim_product表中的每一行代表一个待售产品，包括库存单位（SKU）、描述、品牌名称、类别、脂肪含量、包装尺寸等。fact_sales表中的每一行使用外键表示哪些产品是在特定交易中出售。（为简单起见，如果客户一次购买多种不同的产品，它们将在事实表中表示为单独的行）。日期和时间通常使用维度表来表示，因为这允许对诸如公共假期等日期的附加信息进行编码，从而允许查询区分假期和非假期销售。“星型模式”名称由来：表关系可视化时，事实表居中，周围是一系列维度表；连接到这些表就像星星的光。此模板的一个变体是雪花模式，其中维度进一步细分为子维度。例如，品牌和产品类别可能有单独的表，dim_product表中的每一行都可以再次将品牌和类别作为外键，而不是将它们作为字符串直接存储在dim_product表中。雪花模式比星型模式更规范化，但星型模式是首选，因为对于分析师来说，它更简单。在典型的数据仓库中，表往往很宽：事实表通常超过100列，有时甚至数百列；维度表也可以非常广泛，因为它们包括可能与分析相关的所有元数据。例如，dim_store表可能包含每家商店提供的服务的详细信息，是否有店内面包店，商店的大小，商店开业的日期，上次翻新的时间，距离最近的高速公路等
