谈笑间学会数仓—主题域&&数据域

在之前的文章里虽然没有按照顺序来，但是基本上都介绍了数据仓库建设的大概流程，比如技术架构方案设计、建模方法论、数仓分层、开发规范、数仓建设中的各种事实表、维度表、事务事实表、累计快照表、周期快照表、流水表、增量表、全量表等常用的表。那么下面再来说一下，漏掉的东西。那就是数仓建设中不可缺少的一环—域的划分。域又分为主题域、数据域，如何划分呢？一起来看一下吧～

为什么会有域的概念呢？

首先来看看数据仓库的定义吧，数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

主题域已经体现出来了。

还有种说法是这样的：数据仓库是面向主题（数据综合、归类并进行分析利用的抽象）的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。

数据域已经体现出来了。

主题域

主题

主题是与传统数据库的面向应用相对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。每一个主题对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。

主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供应是否及时，以及材料质量状况等。

数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、产品、订单和财务或是其他某项事务或活动。

主题域

主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

主题域、主题、实体间关系

主题设计是对主题域进一步分解，细化的过程。主题域下面可以有多个主题，主题还可以划分成更多的子主题，而实体则是不可划分的最小单位。主题域、主题、实体的关系如下图所示：

可以显而易见的看出，主题域是一个更大的概念，主题是略次之，实体最小，这里的实体表示的是实体对象（对应企业中某一宏观分析领域所涉及的分析对象）。

主题域的获取

主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

比如，对于Adventure Works Cycle这种类型的公司管理层需要分析的主题一般包括供应商主题、商品主题、客户主题和仓库主题。其中商品主题的内容包括记录超市商品的采购情况、商品的销售情况和商品的存储情况；客户主题包括的内容可能有客户购买商品的情况；仓库主题包括仓库中商品的存储情况和仓库的管理情况等。

确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。对于图3-31的4个主题及其在企业中的业务关系可以确定边界。

主题的使用

由于数据仓库的设计是一个螺旋发展的过程，在刚开始，没有必要在数据仓库的数据库中体现所有的主题，选择最重要的主题作为数据仓库设计的试金石是很有必要的。因此使用主题首先是找到需要分析的主题域。

例如在AdventureWorksDW数据仓库的概念模型设计中，在对需求进行分析后，认识到“商品”主题既是一个销售型企业最基本的业务对象，又是进行决策分析的最主要领域，因而把“销售分析”主题域定义为要首先建立的主题。通过“商品”主题的建立，经营者就可以对整个企业的经营状况有较全面的了解。先实施“商品”主题可以尽快地满足企业管理人员建立数据仓库的最初要求，所以先选定“商品”主题进行实施。

通过将主题边界的划分应用到已经得到的关系模型上还能形成原始的概念模型。这一模型是把主题域的划分和事务处理数据库中的表结合起来的模型，例如在上面的例子中，商品主题可能涵盖的关系表有商品表、供应关系表、购买关系表和仓储关系表；仓库主题可能涵盖的关系表有仓库关系表、仓库表、仓库管理关系表和管理员表。

数据域

概念

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

数据域是DWR层的顶层划分，是对企业业务的抽象提炼，面向业务分析，包含当前所有业务需求，也便于未来扩展。比如：货都是业务过程。采购域、供应链域、业务过程与最终的事实。

数据域的使用

数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。例如A公司电商营销业务板块可以划分为如下数据域，数据域中每一部分都是实际业务过程经过归纳抽象之后得出的。

数据域	业务过程
会员店铺域	注册、登录、装修、开店、关店
商品域	发布、上架、下架、重发
日志域	曝光、浏览、点击
交易域	下单、支付、发货、确认收货
服务域	商品收藏、拜访、培训、优惠券领用
采购域	商品采购、供应链管理

数据域 VS 主题域

数据域和主题域到底有什么区别呢？

”主题域通常是联系较为紧密的数据主题的集合“并不矛盾，只是所站的视角不同，“数据主题集合”的观点从数据着眼，前提是已经经过分析、梳理列出所有可能的数据主题，此处数据主题是细粒度的，是从微观到宏观；“边界论”的观点中，某个主题是分析的主题，是宏观概念，而非数据主题。

个人感觉

由于很多人觉得这里定义不够严谨，特此将主题域抹去，暂定主题域&数据域同级，暂不放在一起进行比较

主题域和数据域往往大家都当做一种域来处理了。如果不当成一组来处理的话，非要存在包含关系的话，那么也可以这样操作。

主题域：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程。针对公共明细层（DWD）进行主题划分。
主题：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程。针对公共明细层（DWD）进行主题划分。

数据域：面向业务分析，将业务过程或者维度进行抽象的集合。针对公共汇总层（DWS）进行数据域划分。

“数据主题集合”的观点从数据着眼，前提是已经经过分析、梳理列出所有可能的数据主题，此处数据主题是细粒度的，是从微观到宏观。

***如果觉得上述描述有不准确的地方，请拿出官方（官方书籍）来证明，我也可以借此来学习一下，喷子、杠精请绕行，谢谢~ ***