数据仓库维度建模思维导图
------ 基于《The Data Warehouse Toolkit, 3rd Edition》（第三版修订版）
一、核心架构与原则
维度建模 (Dimensional Modeling)
- 解释：一种以业务过程为中心的设计方法，通过事实表和维度表构建星型结构。旨在优化查询性能并适应业务变化，是 Kimball 方法论的核心。
- 出处：第1章 (p1), 第2章 (p37), p7
- 使用场景：几乎所有现代数据仓库项目，如零售销售分析、客户行为分析。
- 注意事项 ：
- 必须与业务需求紧密结合，避免纯技术驱动。
- 简单性是其最大优势，不应为"先进"而复杂化。
星型模式 (Star Schema)
- 解释：由一个中心事实表连接多个去规范化的维度表的数据库架构。结构简单直观，能显著减少连接操作，提升 BI 工具查询效率。
- 出处：第1章 (p16), 第2章 (p40), 图1-3 (p8)
- 使用场景：所有基于维度建模的 BI 报表和仪表盘的底层数据结构。
- 注意事项 ：
- 应优先于雪花模式。
- 过度规范化会损害性能和用户体验。
业务过程 (Business Process)
- 解释：企业中发生的具体事件或活动（如销售、下单），是维度建模的起点。每个业务过程通常对应一个事实表，定义了数据的粒度。
- 出处：第3章 (p68, p70), 第6章 (p168), 第17章 (p414)
- 使用场景：选择建模"订单管理"、"财务核算"或"客户服务"等具体流程。
- 注意事项 ：
- 必须是可度量的、原子级的业务事件。
- 避免选择模糊或无法量化的过程。
数据粒度 (Grain)
- 解释：事实表中每一行数据所代表的业务细节程度（如"单次交易"）。粒度是建模的第一原则，决定了数据的深度和灵活性，一旦确定不可更改。
- 出处：第3章 (p74), 第4章 (p120), 第6章 (p168)
- 使用场景：在设计"零售销售"事实表时，确定是按"每笔交易"还是"每件商品"作为一行。
- 注意事项 ：
- 粒度声明必须绝对精确。
- 如果粒度不一致，会导致聚合错误和分析失真。
数据仓库总线 (Data Warehouse Bus)
- 解释：一种企业级架构框架，通过共享的一致性维度和事实将独立的数据集市集成为整体。确保不同部门数据的一致性和可集成性，避免数据孤岛。
- 出处：第4章 (p123--125 图4-1), 第5章 (p141)
- 使用场景：规划和构建一个集成的、可扩展的企业级数据仓库。
- 注意事项 ：
- 需要跨部门协作和数据治理支持。
- 成功依赖于对一致性维度的严格遵守。
一致性维度 (Conformed Dimension)
- 解释：在不同数据集市或事实表中具有相同定义、属性和键值的维度表。它是实现跨主题域"钻取"操作和企业数据集成的关键。
- 出处：第4章 (p130), 第8章 (p256), 第11章 (p304), 第16章 (p386), 第18章 (p431)
- 使用场景：使用同一个"客户维度"连接"销售事实表"和"服务请求事实表"，分析客户购买与服务的关系。
- 注意事项 ：
- 必须在项目初期就定义并发布，供所有团队复用。
- 后期强行统一成本极高。
- 补充 ：还需确保层级结构一致（如地区分级顺序），否则无法正确钻取。
一致性事实 (Conformed Fact)
- 解释：在不同事实表中具有相同定义和计算逻辑的度量值。确保跨业务过程的比较和分析结果准确无误。
- 出处：第4章 (p138--139), 第16章 (p386)
- 使用场景：确保"销售收入"在"销售事实表"和"利润表"中的计算方式完全一致。
- 注意事项 ：
- 计算口径必须在所有地方保持一致。
- 微小差异会导致"钻取"结果不匹配。
反规范化 (Denormalization)
- 解释：故意将多个相关表合并或冗余存储数据，以减少查询时的连接操作。在数据仓库中用于牺牲少量存储空间换取显著的读取性能提升。
- 出处：第2章 (p47), 第3章 (p84), p104（对比雪花）
- 使用场景：在"产品维度"中直接包含"品牌"、"品类"等上游属性，避免多层连接。
- 注意事项 ：
- 是维度建模的基石。
- 不要因"浪费空间"而犹豫，性能提升远大于存储成本增加。
雪花模式 (Snowflake Schema)
- 解释：维度表进一步规范化，拆分成多个子表的架构形式。Kimball 指出这通常增加查询复杂度，仅在维度属性极多或复用率极高时才考虑使用。
- 出处：第2章 (p50), 第3章 (p104), 第8章 (p256)
- 使用场景：当"地区维度"过于庞大时，将其拆分为"国家"、"省"、"市"三个子表。
- 注意事项 ：
- 警告：应尽量避免。
- 除非有压倒性理由（如维度表过大影响性能，或需被多个异构系统共享），否则坚持星型模式。
一致性总线矩阵 (Conformed Bus Matrix)
- 解释：企业级集成蓝图，列出所有业务过程及其使用的一致性维度。是 DW/BI 项目的顶层设计文档，指导长期发展。
- 出处：第4章 (p125 图4-1), 第18章 (p431)
- 使用场景：协调跨部门开发节奏，确保系统可扩展、可集成。
- 注意事项 ：
- 必须由业务与技术共同签署。
- "空单元格"表示待实现的集成点，是项目路线图的重要依据。
- 是项目成败的战略地图。
因果维度 (Causal Dimension)
- 解释：用于解释"为什么"某个指标发生变化的维度，例如促销活动、天气、竞争对手行为等。它不是业务事件本身，而是影响因素。
- 出处：第3章 (p89--90), 第10章 (p284)
- 使用场景：分析"某月销售额下降"是否因"促销结束"或"竞品上市"。
- 注意事项 ：
- 需独立采集和管理，常来源于外部系统。
- 可与行为标签结合使用，增强归因能力。
二、事实表设计
事实表 (Fact Table)
- 解释：存储业务过程度量值（如金额、数量）的核心表，包含外键指向维度表。它是数据分析的计算基础，记录了"发生了什么"。
- 出处：第1章 (p10), 第2章 (p41), 第3章 (p79)
- 使用场景：记录每一次销售交易、银行账户流水、网站点击事件。
- 注意事项 ：
- 避免在事实表中存放文本描述。
- 所有描述性信息都应在维度表中。
事务事实表 (Transaction Fact Table)
- 解释：记录特定时间点发生的原子级业务事件（如刷卡消费）。每一行代表一个具体动作，粒度最细，支持最灵活的分析。
- 出处：第2章 (p43), 第3章 (p79), 第4章 (p116), 第6章 (p168)
- 使用场景："POS机每笔销售记录"、"ATM机每次取款记录"。
- 注意事项 ：
- 确保粒度的一致性。
- 同一事实表中的所有行必须遵循相同的粒度规则。
周期快照事实表 (Periodic Snapshot Fact Table)
- 解释：以固定时间间隔（如每天、每月）记录业务状态的累积数据。用于分析趋势和存量，即使期间没有发生事务也会生成记录。
- 出处：第2章 (p43), 第4章 (p120), 第9章 (p267), 第16章 (p385)
- 使用场景："每日银行账户余额"、"每月末产品库存量"。
- 注意事项 ：
- 需要强大的调度机制来确保准时生成。
- 快照的"截止时间"必须清晰定义。
累积快照事实表 (Accumulating Snapshot Fact Table)
- 解释：记录具有明确生命周期的业务过程（如订单履行），一行数据随流程进展不断更新。包含多个时间戳，用于分析流程效率和延迟。
- 出处：第2章 (p44), 第4章 (p121), 第6章 (p194), 第14章 (p343)
- 使用场景："订单履约流程"（从下单、支付、拣货、发货到签收）。
- 注意事项 ：
- 警告：事实表行会被反复更新，对数据库性能和 ETL 设计提出更高要求。
- 需要精心设计更新逻辑。
- 推荐预计算"滞后/持续时间事实"以加速分析。
无事实事实表 (Factless Fact Table)
- 解释：仅包含维度外键而不包含数值度量的事实表，用于记录事件的发生与否。常用于统计覆盖率、出勤率等二元状态场景。
- 出处：第2章 (p44), 第9章 (p278), 第13章 (p329)
- 使用场景：记录学生的"每日出勤"情况，或医院的"患者就诊"预约。
- 注意事项 ：
- 虽然没有数值，但它仍然是强大的分析工具。
- 可与其他事实表联合分析（如分析缺勤对业绩的影响）。
可加性事实 (Additive Fact)
- 解释：可以在所有维度上进行汇总相加的度量值（如销售额）。这是最常见的事实类型，支持任意粒度的聚合分析。
- 出处：第2章 (p42), 第6章 (p187)
- 使用场景："销售金额"、"销售数量"。
- 注意事项 ：
- 是最理想的事实类型。
- 应尽可能将度量设计为完全可加的。
半可加性事实 (Semi-additive Fact)
- 解释：只能在部分维度上相加的度量值（如库存量，可加产品但不能加时间）。需要特殊的聚合逻辑，通常对时间维度取最后值。
- 出处：第2章 (p42), 第6章 (p187)
- 使用场景："银行账户余额"、"仓库库存量"。
- 注意事项 ：
- BI 工具必须知道如何聚合。
- 通常需要在语义层中明确定义聚合函数（如
LAST_VALUE_OVER_TIME）。
非可加性事实 (Non-additive Fact)
- 解释：在任何维度上都不能直接相加的度量值（如比率、温度）。通常需要在底层粒度计算后，再在应用层进行平均或其他运算。
- 出处：第2章 (p42), 第6章 (p187)
- 使用场景："利润率"、"平均单价"。
- 注意事项 ：
- 警告：应避免存储已聚合的比率，除非是预计算摘要用于性能优化，且需明确标注。
- 推荐做法：总是存储分子和分母（如销售额和销售数量），让 BI 工具在查询时动态计算。
退化维度 (Degenerate Dimension)
- 解释：直接从源系统保留在事实表中的标识符（如订单号、发票号），没有对应的维度表。用于唯一标识事务或进行简单过滤。
- 出处：第3章 (p93), 第6章 (p178), 第15章 (p368), 第19章 (p469)
- 使用场景：将"发票编号"作为字段直接放在"销售事实表"中。
- 注意事项 ：
- 仅用于没有描述性属性的标识符。
- 若该标识符有关联属性，应创建维度表。
- ❌ 不推荐 ：将精确时间戳（如
txn_timestamp）放入退化维度 → 应使用独立的time或datetime维度。
聚集事实表 (Aggregate Fact Table)
- 解释：基于原子事实表预先聚合生成的汇总表（如按天、按地区汇总）。用于大幅提升常用查询的性能，是物理优化的关键手段。
- 出处：第2章 (p45), 第19章 (p481), 第20章 (p517--518)
- 使用场景：为"月度销售报表"预计算"按产品类别、按地区的月销售额"。
- 注意事项 ：
- 警告：必须与底层原子事实表保持同步。
- 若聚合表和明细表结果不一致，会严重损害用户信任。
- 补充 ：应建立聚合感知的语义层，防止用户对聚合表再次聚合（嵌套聚合风险）。
合并事实表 (Consolidated Fact Table)
- 解释：将来自不同业务过程、但具有相同粒度和维度的多个事实表合并成一个单一的、更宽的事实表。目的是简化模型，便于跨业务过程的分析。
- 出处：第2章 (p45), 第7章 (p224--226)
- 使用场景：将"销售交易"、"采购交易"和"退货交易"合并到一个"财务交易"事实表中。
- 注意事项 ：
- 警告 ：前提是粒度、维度键集合和上下文语义必须一致。
- 若粒度不同，则不能合并，否则会造成数据重复或丢失。
度量类型维度 (Measure Type Dimension)
- 解释：一种特殊维度，用于统一多个异质度量值（如收入、成本、利润）进入同一事实表。通过引入"度量类型"列实现"交叉表转为长格式"，支持灵活分析。
- 出处：第2章 (p65), 第7章 (p224), p226（OLAP）
- 使用场景：将损益表中的"销售收入"、"运营成本"、"净利润"三项分别作为不同"度量类型"存入同一个"财务快照事实表"。
- 注意事项 ：
- 适用于稀疏事实表。
- 在 BI 工具中需启用"透视"功能才能还原原始表格视图。
滞后/持续时间事实 (Lag/Duration Facts)
- 解释：在累积快照中预计算里程碑之间的时间差（如"下单到发货天数"），避免运行时计算。极大提升分析效率。
- 出处：第6章 (p196), 第12章 (p321)
- 使用场景：分析供应链效率、客户响应速度、理赔周期。
- 注意事项 ：
- 推荐使用，避免复杂 SQL 计算。
- 可支持上百种潜在延迟组合。
- 技巧：只需存储"相对起点的偏移量"，即可通过减法得到任意两点间延迟。
分配事实 (Allocated Facts)
- 解释：将头级别事实（如运费）按规则分摊至明细行，使所有维度均可切片分析。
- 出处：第6章 (p184), 第15章 (p363)
- 使用场景：处理订单级费用分配到商品行。
- 注意事项 ：
- 分配逻辑必须透明且业务认可。
- 可避免创建头级事实表。
固定时间桶 (Fixed Time Series Buckets)
- 解释 ：一种反模式：将12个月度指标硬编码为12个字段（如
Jan_Sales,Feb_Sales）。应避免，改用标准日期维度+行模式。 - 出处：第2章 (p302--303)
- 使用场景：遗留系统常见，如 ERP 中的月度累计字段。
- 注意事项 ：
- 灵活性差，难以扩展。
- 所有时间属性需由应用层维护 → 推荐重构为标准维度模型。
三、维度表设计与缓慢变化维度 (SCD)
维度表 (Dimension Table)
- 解释：存储描述性上下文信息（如谁、什么、哪里）的表，包含文本属性和层次结构。它是查询的入口，用于过滤、分组和标记数据。
- 出处：第1章 (p13), 第2章 (p46), 第3章 (p79)
- 使用场景：产品目录、客户档案、日历日期表。
- 注意事项 ：
- 应设计为宽表，包含尽可能多的描述性属性，以支持全面的分析。
代理键 (Surrogate Key)
- 解释：数据仓库中生成的整数主键，用于替代源系统的自然键。它解耦了数仓与源系统，是处理 SCD 和整合多源数据的基础。
- 出处：第2章 (p46), 第3章 (p98), 第19章 (p469), 第20章 (p506)
- 使用场景：为"客户维度"分配唯一的数字 ID，即使客户的手机号（自然键）发生变更。
- 注意事项 ：
- 必须是简单的整数，不应包含任何业务含义。
- 永远不要使用源系统的自然键作为主键。
缓慢变化维度 (Slowly Changing Dimension, SCD)
- 解释：处理维度属性随时间变化（如客户地址变更）的策略集合。需根据业务对历史追踪的需求选择合适的策略，常混合使用。
- 出处：第5章 (p148), 第19章 (p464)
- 使用场景：客户搬家导致"居住地址"变更，产品价格调整导致"单价"变更。
- 注意事项 ：
- 没有放之四海而皆准的策略。
- 可组合使用多种类型（如 Type 2 + Type 6）。
| 类型 | 解释 | 出处 | 使用场景 | 注意事项 |
|---|---|---|---|---|
| Type 0: Retain Original | 属性永不改变，忽略更新 | p148, p465 | 身份证号、出生日期 | 适用于静态属性 |
| Type 1: Overwrite | 直接覆盖，不留历史 | p149, p465 | 更正拼写错误 | ❗ 历史信息永久丢失 |
| Type 2: Add New Row | 插入新行，保留历史 | p151, p466, 图5-2 (p153) | 地址、岗位变动 | 最常用，推荐 |
| Type 3: Add New Attribute | 增加"旧值"列 | p154, p467 | 仅需对比前后两状态 | 功能有限，仅追溯一步 |
| Type 4: Add Mini-Dimension | 剥离高频变属性 | p156, p467, p289, p381 | 信用等级、收入区间 | 配合"带状化"使用 |
| Type 5: Mini-Dim + Type 1 Outrigger | 主维保留当前键 | p160, p468, 图5-14 (p161) | 同时支持当前与历史分析 | 增加ETL复杂性 |
| Type 6: Add Type 1 to Type 2 | 在Type 2中加当前列 | p160, p468 | 简化当前状态查询 | 违背"行不变"原则 |
| Type 7: Dual Type 1 & 2 | 同时维护两个维度 | p162, p468 | 灵活切换分析视角 | ❗ 最复杂，慎用 |
杂项维度 (Junk Dimension)
- 解释：将多个低基数、无序的标志位或状态码（如"是否加急"、"支付状态"）合并到一个维度表。避免事实表中充斥大量外键。
- 出处：第6章 (p179), 第16章 (p392), 第19章 (p471)
- 使用场景：将"现金/信用卡"、"是否使用优惠券"、"是否包邮"等标志组合成"交易特征"维度。
- 注意事项 ：
- 警告：若组合属性值过多，会产生"组合爆炸"，导致维度表过大。
- 可通过 CROSS JOIN 生成后裁剪。
角色扮演维度 (Role-Playing Dimension)
- 解释：同一个维度表在事实表中被多次引用，扮演不同角色（如订单日期、发货日期都引用时间维）。
- 出处：第6章 (p170), 第14章 (p345), 第19章 (p474)
- 使用场景：在订单事实表中，同时引用"日期维度"作为"下单日期"和"发货日期"。
- 注意事项 ：必须为每个引用创建带角色前缀的别名（如
ORDER_DATE_KEY,SHIP_DATE_KEY）。
时间维度 (Time Dimension)
- 解释：专门设计的包含日期、星期、月份、节假日等丰富属性的维度表。几乎存在于所有事实表中，是时间序列分析的基础。
- 出处：第2章 (p48), 第3章 (p79), 第6章 (p170), 第14章 (p345)
- 使用场景：在任何需要按时间分析的报表中，如"按月销售额趋势"。
- 注意事项 ：
- 应预先生成未来几年的日期。
- 包含业务特有的日历（如财年、营业日）。
外接维度 (Outrigger Dimension)
- 解释：维度表引用另一个维度（如客户维引用"开户日期维"），形成间接连接。属于轻度雪花结构，可用于地理人口统计等场景。
- 出处：第2章 (p50), 第3章 (p106), 第8章 (p256)
- 使用场景：将县级人口统计数据作为客户维的外接维度。
- 注意事项：应少用，可用视图封装隐藏复杂性。
文本注释维度 (Text Comment Dimension)
- 解释：存储大段非结构化文本（如客服记录、医生诊断描述），通常作为 junk dimension 的扩展。
- 出处：第2章 (p65), 第19章 (p472)
- 使用场景：医疗病历、客户服务工单备注。
- 注意事项：不宜频繁 JOIN，建议全文索引或外部存储链接。
可变深度/锯齿状层次结构 (Variable Depth/Ragged Hierarchy)
- 解释：维度内部存在的递归层级关系（如员工汇报线、物料BOM），其深度不固定，形状不规则。通常通过桥接表或路径串建模。
- 出处：第7章 (p215), 第9章 (p271), 第10章 (p286)
- 注意事项 ：
- 警告：直接递归查询性能差。
- 应在 ETL 中通过"桥接表"或"路径字符串"将其展平。
桥接表 (Bridge Table)
- 解释：用于建模多对多关系或共享所有权的辅助表，包含父子路径及权重。
- 出处：第7章 (p219), 第9章 (p274)
- 注意事项：常用于医疗、人力资源等领域。
路径字符串 (Pathstring)
- 解释 ：在维度行中存储从根节点到当前节点的完整路径（如
/CEO/CFO/Controller）。 - 出处：第7章 (p221)
- 优劣：轻量但缺乏灵活性，结构调整后需重建。
四、复杂场景建模模式
1. 多对多与共享所有权
- 桥接表（含权重）
- 时间有效桥接（双时间戳）
- 示例：员工技能、客户偏好
2. 异构对象统一管理
- 超类型/子类型（Supertype/Subtype）
- 收缩一致性维度（Shrunken Conformed Dimension）
- 示例：银行账户、保险保单、医疗服务
3. 动态属性与高频变化
- 微型维度（Mini-Dimension）
- 动态值分箱（Value Banding）
- Type 4--7 SCD 联用
- 示例：信用评级、收入区间
4. 递归与层次结构
- 桥接表 vs 路径字符串
- 管理员角色递归查询
- 示例：组织架构、物料清单（BOM）
5. 灵活分析与实验支持
- 热插拔维度
- 度量类型维度
- A/B测试标签设计
- 行为标签（Behavior Tags）
五、ETL 与生命周期方法论
主要出处：第19章 (p449), 第20章 (p497), 第17章 (p404)
ETL 子系统四大模块
| 模块 | 子系统编号 | 功能 |
|---|---|---|
| 1. 抽取 | #1--#3 | 数据剖析、变更捕获、抽取系统 |
| 2. 清洗与一致性 | #4--#8 | 数据清洗、标准编码、一致性维度映射 |
| 3. 交付 | #9--#21 | SCD处理、代理键分配、事实表构建、聚集生成 |
| 4. 管理 | #22--#34 | 调度、日志、通知、备份、安全、版本控制、元数据 |
关键子系统详解
| 组件 | 解释 | 出处 |
|---|---|---|
| 审计维度 (Audit Dimension) | 存储 ETL 运行上下文（如批次ID、作业名、加载时间），用于追踪数据血缘和质量问题。 | p478, p502 |
| 元数据管理器 (Metadata Repository Manager) | 统一管理技术、业务、操作元数据，支撑 BI 工具自动发现和语义层构建。 | p490, p502 |
| 错误事件模式 (Error Event Schema) | 记录 ETL 中所有数据质量问题，支持监控与修复。 | p458--460, Fig 19-1 |
| 维度提供系统 | #19 | 提取维度数据、处理SCD、分配代理键 |
| 事实提供系统 | #20 | 提取事实数据、清洗、准备加载 |
| 数据血缘 (Data Lineage) | 描述数据从源头到最终报表的流动路径，是合规与调试的关键。 | p447--448, p490 |
| 维度锚定 (Dimension Anchoring) | 通过一致性维度绑定数据，确保集成正确性。 | p539 |
六、现代扩展议题
出处：第20章 (p497--524 实时/低延迟), 第21章 (p527--542 大数据架构)
| 概念 | 解释 | 出处 |
|---|---|---|
| 列式数据库 (Columnar DB) | 按列存储，极大提升扫描性能，缓解"蜈蚣事实表"问题。 | p51, p530 |
| MapReduce/Hadoop 架构 | 用于大规模非结构化数据处理，与传统 DW 协同工作。 | p530 |
| 数据湖集成 | 将 Hadoop 或云存储作为原始层，与结构化 DW 分层协作。 | p534--536 |
| 实时处理 (Streaming ETL) | 支持近实时加载，满足低延迟分析需求。 | p522--524 |
| 嵌入式分析 (In-Database Analytics) | 在数据库内执行机器学习模型，减少数据移动。 | p538--539 |
| Big Data 最佳实践 | 包括架构、建模、治理等方面的指导原则。 | p531--541 |
| 数据虚拟化 (Data Virtualization) | 提供逻辑视图而非物理复制，支持快速原型设计。 | p540 |
| 合规性下的不可变数据 | 所有变更必须 insert 新行，禁止 overwrite/delete → Type 1/3 失效 | p468, p476 |
七、反模式与常见陷阱
出处：第21章 "Common Dimensional Modeling Mistakes to Avoid" + 全书归纳
| 错误 | 正确做法 | 出处 |
|---|---|---|
| 把文本描述放在事实表中 | 移入维度表 | p397 (Mistake 10) |
| 为节省空间截断描述字段 | 宁愿多占空间也要完整保留 | p398 (Mistake 9) |
| 对维度过度规范化（雪花化） | 坚持反规范化星型模式 | p104 |
| 在事实表中存储"平均数" | 存储分子分母，运行时计算 | p42 |
| 使用自然键作为主键 | 使用整数代理键 | p98 |
| 忽略 SCD 类型选择的重要性 | 根据业务需求选型 | p148 |
| 创建超宽"蜈蚣事实表" | 使用桥接表或列式存储缓解 | p530 |
| 让 ETL 直接更新事实表行 | 使用插入+删除两步法保证一致性 | p476 |
| 忽视数据血缘与审计 | 建立审计维度和元数据管理 | p478--490 |
| 用报告反向推导模型 | 从业务过程出发正向设计 | p400 (Mistake 3) |
| 使用 ERD 思维设计星型模型 | 从粒度和上下文出发 | p8, p74 |
| 混合不同粒度的事实 | 拆分为独立事实表 | p184 |
| 在维度中使用复合主键 | 使用单一代理键 | p98 |
附录：术语中英文对照表
| 中文 | 英文 |
|---|---|
| 事实表 | Fact Table |
| 维度表 | Dimension Table |
| 事务事实表 | Transaction Fact Table |
| 周期快照 | Periodic Snapshot |
| 累积快照 | Accumulating Snapshot |
| 无事实事实表 | Factless Fact Table |
| 代理键 | Surrogate Key |
| 自然键 | Natural Key |
| 缓慢变化维度 | Slowly Changing Dimension (SCD) |
| 杂项维度 | Junk Dimension |
| 角色扮演维度 | Role-Playing Dimension |
| 外接维度 | Outrigger Dimension |
| 桥接表 | Bridge Table |
| 路径字符串 | Pathstring |
| 数据仓库总线 | Data Warehouse Bus |
| 一致性维度 | Conformed Dimension |
| 一致性总线矩阵 | Conformed Bus Matrix |
| ETL | Extract, Transform, Load |
| 数据血缘 | Data Lineage |
| 元数据 | Metadata |