一、什么时候主题？
数据仓库 主题(Subject) 是在较高层次上将企业信息系统中某一分析对象（重点是分析的对象）的数据进行整合、归类并分析的一种范围，属于一个抽象概念，简单点说每一个主题对应一个宏观分析领域。目的是便于数据的管理和应用。
二、什么是主题域？
主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域(也说是对某个主题进行分析后确定的主题的边界。) 这种划分与Kimball思想更为相似，自下而上的方式，根据业务需求分析视角进行划分。
这是对主题域的描述被归于集合论，还有一种叫做是边界论
边界论的论点是 “主题域是对某个主题进行分析后确定的主题的边界“，这点个人感觉和 Inmon 指导思想类似，理清主题之间的边界，由ER模型进行逻辑转化，对某一主题域的分析，需要先确定这个主题的关系边界，然后再进行逻辑建模。
两者并不矛盾，只是所站的视角不同，边界论是先从细微处也就是微观延伸到宏观，而集合论则是从宏观到微观的过程。
举例说明：
1. 对于一个erp系统而言，"销售分析"就是一个分析领域，这个"销售分析"所涉及到的分析对象有商品、供应商、顾客、仓库等，
那么数仓主题就确定为商品主题、供应商主题、顾客主题、仓库主题，"销售分析"就可以作为一个主题域；
2. 如果"产品分析"是一个分析领域，"产品分析"所涉及到的分析对象为商品、地域、时间、类别等，
那么数仓的主题可以确定为商品主题、地域主题、时间主题、类别主题，"产品分析"可以作为一个主题域。三、主题的划分
主题的划分和设计是对主题域进一步的分解，细化的过程。主题域下面可以有多个主题，主题还可以划分成更多的子主题，主题和主题之间的建设可能会有交叉现象，而实体则是不可划分的最小单位。
mermaid
graph TD
subgraph 主题域
subgraph 主题
A((实体))
end
end 主题域是一个更大的概念，主题是略次之，实体最小，这里的实体表示的是实体对象（对应企业中某一宏观分析领域所涉及的分析对象）,在维度建模的方法论上也可以说实体和维度某些概念是相似的。
在进行数据仓库设计时，一般是先基于一个主题或某部分主题进行优先建设，所以在大多数数据仓库的设计过程中都有一个主题域的选择过程，主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象
1、按照业务(功能模块/业务线)或业务过程划分
比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
2、按照部门划分
比如公司里面的人力、财务、销售、运营等，运营域中可能会有工资支出分析、活动宣传效果分析等主题。
3、按照行业案例分析划分
在某些行业，比如电信、金融都是最早建设数仓的行业，都有一些规范，比如IBM 公司的 BDWM 九大金融主题模型,Teradata 公司的 FS-LDM 十大金融主题模型，都是行业应用比较广泛的标准，如果是这两个行业就可以参考构建自己的企业数据仓库模型规范。
比如TD FS-LDM (Financal Services Logical Data Model)，适用于证券、银行、保险
十大主题：
当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。
IBM BDWM (Banking Date Warehouse Model)
银行九大主题：
关系人、合约、条件、产品、地点、分类、业务方向、事件、资源项目四、数据域是什么？
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
在实际过程中可以把主题域和数据域都当做一种域来处理了，不必纠结
主题域：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程，针对公共明细层（DWD）进行主题划分。数据域：面向业务分析，将业务过程或者维度进行抽象的集合，针对公共汇总层（DWS）进行数据域划分。
| 数据域 | 业务过程 |
|---|---|
| 会员店铺域 | 注册、登陆、装修、开店、关店 |
| 商品域 | 发布、上架、下架、重发 |
| 日志域 | 曝光、浏览、单击 |
| 交易域 | 下单、支付、发货、确认收货 |
| 服务域 | 商品收藏、拜访、培训、优惠卷领用 |
| 采购域 | 商品采购、供应链管理 |
具体实例
1、马蜂窝数仓
参考链接： https://blog.csdn.net/Alex_81D/article/details/128020496
马蜂窝订单交易模型的建设为例，基于业务生产总线的设计是常见的模式，首先调研订单交易的完整过程，定位过程中的关键节点，确认各节点上发生的核心事实信息。
| 数据域/主题域 | 主题 | 主题关键字及简写 | 涵盖内容 |
|---|---|---|---|
| 交易 | 订单 | Order(ord) | 酒店、大交通、自由行等类似订单 |
| 交易 | 财务 | Finance(fin) | 财务、支付、结算 |
| 交易 | 营销 | Marketing(mkt) | 市场营销、促销、优惠卷 |
| 交易 | 产品 | Product(prd) | 平台售卖的产品、商品、SKU等相关属性及供应链如库存等 |
| 交易 | 客服 | Customer Service Center(csc) | 呼叫中心、IM等 |
| 流量 | 流量 | Flow(flw) | 各类终端流量、业务流量、渠道流量等 |
| 内容 | 内容 | Community(cmt) | 内容5大业务线、目的地、POI等 |
| 参与人 | 用户 | User(usr) | 平台个人用户 |
| 参与人 | 设备 | Device(dvc) | 各类设备：手机、iPad等 |
| 参与人 | 商家 | Vendor(vdr) | 供应商、平台卖家等 |
| 参与人 | 员工 | employee(epl) | 马蜂窝员工 |
2、网易云音乐数仓主题、主题域划分案例
网易云音乐将一级主题域划分为参与者、服务及产品，版权及协议、公共、事实这5个大的主题域，二级细节分类按照业务过程抽象获得。
其中一致性维度包括：用户、房主、房间、礼物、设备、动态、坑位、进房入口等，主要是对应各个主题和业务过程
| 一级数据域 | 二级数据域 | 业务过程 | 一致性维度 |
|---|---|---|---|
| 参与者 | 用户 | ||
| 参与者 | 房主 | ||
| 参与者 | 房间 | ||
| 事实 | 交易营收 | 收费 | |
| 事实 | 交易营收 | 收益 | |
| 事实 | 交易营收 | 充值 | |
| 事实 | 交易营收 | 提现 | |
| 事实 | 社交互动 | 进房 | |
| 事实 | 社交互动 | 出房 | |
| 事实 | 社交互动 | 发言 | |
| 事实 | 社交互动 | 上麦 | |
| 事实 | 社交互动 | 下麦 | |
| 事实 | 社交互动 | 分享 | |
| 事实 | 社交互动 | 关注 | |
| 事实 | 社交互动 | 收藏 | |
| 事实 | 社交互动 | 匹配 | |
| 事实 | 社交互动 | 私信 | |
| 事实 | 社交互动 | 点赞 | |
| 事实 | 社交互动 | 评论 | |
| 事实 | 日志流量 | 点击 | |
| 事实 | 日志流量 | 浏览 | |
| 事实 | 日志流量 | 启动 | |
| 事实 | 日志流量 | 曝光 | |
| 事实 | 营销活动 | push | |
| 事实 | 营销活动 | 拉新 | |
| 事实 | 安全风控 | ||
| 事实 | 搜索 | ||
| 事实 | AB测试 | ||
| 服务及产品 | UGC | ||
| 服务及产品 | PGC | ||
| 服务及产品 | 公共资源 | ||
| 服务及产品 | 特权服务 | ||
| 服务及产品 | 音乐协议 | ||
| 服务及产品 | 直播协议 | ||
| 公共 | 日期 | ||
| 公共 | 设备 |