[分享]微软BI专题-数据仓库本质解析及典型设计技巧

关注

转载最新推荐文章于 2026-08-24 09:41:35 发布 951 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

数据仓库究竟是什么？它和事务交易处理系统（OLTP）又有什么区别？初次接触它的朋友往往觉得它很神秘、很复杂，其实不然。今天就和大家来认识一下数据仓库的本质，以及在实施商务智能过程中它的一些设计技巧。

      Ralph Kimball，数据仓库（Data Warehouse，DW）领域最权威的专家之一，曾下过这样的结论：BI系统=数据仓库。或许这种说法有一定的片面性，经不起咬文嚼字的推敲，但从中我们却不难看出数据仓库在BI系统中举足轻重的地位。
      仔细想想，的确如此。几乎所有的BI项目，都是在数据仓库这个“大舞台”之上“演出”的，它就像是BI系统的心脏，源源不断地为前端提供新鲜的血液——最新的业务数据，有了这些数据，我们才会看到前端详尽的报表、直观的分析和神奇的预测。
      数据仓库究竟是什么呢？它和事务交易处理系统（OLTP）又有什么区别？初次接触它的朋友往往觉得它很神秘、很复杂，其实不然。今天就和大家来认识一下数据仓库的本质，以及在实施商务智能过程中它的一些设计技巧。

      概念解析
      目前，关于数据仓库的定义有很多种，都是从不同的角度和层面概括的。著名数据仓库专家W.H.Inmon在其著作《Building the Data Warehouse》一书中有过如下描述：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、稳定的（Non-Volatile）、随时间不断变化（Time Variant）的数据库系统，主要用于企业的决策支持。对于上述概念，结合与OLTP系统的比较，我们可以从以下几个方面来理解数据仓库：
     “遗传”性 从 “数据库”到“数据仓库”，虽然多了一个“仓”字，但却没有改变它数据库的“本性”。从物理上来讲，它依然是一个关系型的数据库，表、字段、主键、索引、键约束等概念，在数据仓库中依然存在，无论数据的组织方式还是在表中二维的存放，数据的存储规则也基本遵循关系型数据库的各种范式。从这个层面来看，数据仓库与普通的数据库系统并无本质区别。
      主题性 OLTP系统是被设计用来处理和存储事务交易数据的，通常一个企业内存在多个OLTP系统，各自之间相互独立。而数据仓库是被设计用来进行决策支持，主要是进行数据分析，因此它的数据组织方式是按主题划分的。主题是一个抽象的概念，是指用户使用数据仓库进行分析时所关注的具体的业务领域。如一个企业的数据仓库中可能包含了财务系统、销售系统、库存系统、人力资源系统等方面的数据，它们都被划分为一个主题（通常对应着一个数据集市）。
      集成性 所谓“ 集成”，也是与OLTP系统相比较而言。OLTP系统通常是与某些特定的应用相关的，数据库之间相互独立，结构不一。而数据仓库中的数据是对原有独立的、分散的、异构的各种OLTP系统（包括文本文件、半结构化文件）中的数据进行了大汇总，并对这些数据进行了清洗和转换，消除了其中的不一致性，统一规范了数据格式，保证了这些数据是关于整个企业的全局性数据。
      稳定性 OLTP系统由于面向事务操作，经常会有增、删、改等操作，所以其中的数据会经常更新。而数据仓库的数据主要供企业决策分析使用，所涉及的数据操作主要是数据查询。数据一旦进入数据仓库，将会被长期保存，一般不会进行修改和删除操作，通常只需要定期进行加载和刷新。
      时变性 既 “稳定”又“时变”，听起来有些矛盾，这更为数据仓库增添了几分神秘色彩。这里说的时变，指的是其中的数据不是一成不变的，而是按一定的时间间隔进行更新的。随着OLTP系统数据的积累，新的数据按时经过转换加工后被源源不断地抽取到数据仓库中。只有数据不断更新，新数据不断的注入，我们基于数据仓库进行的前端分析展现的结果才会更符合企业当前的实际状况，来有效地辅助企业决策。

“外观”解析
前面提到，数据仓库在物理上仍然是一个关系型的数据库系统，那从外观上来看，数据仓库有什么特点呢？如图1所示，是一个比较典型的数据仓库（准确地说是一个数据集市），大家可以看到，与普通的数据库不同，其中的表都以“Dim”或“Fact”开始，这是因为数据仓库中的数据不外乎维度数据和事实数据（元数据除外），为了我们直观上容易判断和以后多维建模过程中便于识别，我们通常在维度表的表名前加“Dim”，在事实表的表名前加“Fact”，当然，这只是一种良好的命名习惯，并不是必须这样来命名。

地位解析
数据仓库在商务智能过程所处的位置如图2所示。
可以看出，数据仓库在整个BI的流程中的地位可以概括为“承前启后”。所谓“承前”，正如前面所提到的，它汇总了来自异构数据源的、经过清洗整合后的数据，使数据与业务系统脱离，保障了业务系统的安全和效率；所谓启后，是因为它为以后建设多维数据库做好了准备，是建立多维数据库的基础和平台。

相关技巧
1、架构模式的选择
数据仓库的架构主要有星型和雪花型两种方式，其结构如图3所示。

      下面从多个角度来比较一下这两种模式的利弊。
      从查询性能角度来看，在OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；但从DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。
      从模型复杂度来看，星型架构更简单。
      从层次概念来看，雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。
      从存储空间角度来看，雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，而相比之下星型架构会产生数据冗余。
      根据我们的项目经验，一般建议使用星型架构。因为我们在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型维度。

2、“键”与“约束”的取舍
      主外键的选择是数据仓库建设过程中一个很重要的方面。事实表中由于引用了多个维度表的主键，这些主键结合起来已经具有唯一性，可以确定唯一的事实记录，所以通常情况下，我们不会再为其设立代理键作为主键，而是为其建立复合主键。
      相比之下，维度表中的情况稍微复杂。维度表中的主键通常有两种选择：自然键（Natural Key），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。另一种是代理键（Surrogate Key），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。
      根据笔者的项目经验，推荐采用第二种，即代理键。原因如下：
      首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。
      其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。
      最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。

      键约束的取舍也是数据仓库设计过程中一个很值得注意的问题。在OLTP系统环境中，数据的完整性通常靠两种方式来保证，一是应用程序的逻辑保证，另一个是数据库结构自身的约束机制。这两种方式相互补充，而数据仓库环境中的情况则完全不同，数据仓库中数据的完整性更依赖于应用程序，也就是ETL系统的保证。
      首先，ETL系统运行时间虽然很长，但其结构是简单的，重复地抓取、清洗、转换、加载动作。与其相比，OLTP系统可能同时在一张表上执行大量并行业务操作。
      其次，事实表的唯一入口是维度表，按照维度建模的思路实现ETL程序，只会产生不准确的维度信息，不可能在事实表中产生重复记录。第三，与OLTP系统相比，数据仓库系统没有交互式人机录入界面，不存在“人为”错误。
      因此，在我们比较关注数据加载时间的情况下，最好从数据仓库中删除一些不必要的约束，其中包括主键约束、外键约束及唯一索引约束，这些约束规则可以在外部得以实施。

3、ODS的运用
ODS（Operational Data Storage，操作型数据存储区）是数据仓库体系结构中的一个可选部分，它具备数据仓库的部分特征和OLTP系统的部分特征。它是“面向主题的、集成的、当前或接近当前的、随时间不断变化的”数据库系统。在什么情况下才需要用到ODS这个环节呢？或者说，ODS起到了什么作用？
ODS在业务系统和数据仓库之间形成一个隔离层，如图4所示。一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中。从这些业务系统对数据进行抽取并不是一件容易的事，此时就需要用到ODS。它在业务系统和数据仓库之间形成一个隔离层，用来存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

ODS还可用来转移一部分业务系统细节查询的功能。在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生很大的压力。而ODS中的数据从粒度、组织方式等各个方面都保持了与业务系统相一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低了业务系统的查询压力。
ODS还可以完成数据仓库中不能完成的一些功能。一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。