维度表和事实表

维度表和事实表

一、维度表

维度表:一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如:用户、商品、日期、地区等。

维表的特征:

  • 维表的范围很宽(具有多个属性、列比较多)
  • 跟事实表相比,行数相对较小:通常< 10万条
  • 内容相对固定:编码表

二、事实表

事实表中的每行数据代表一个业务事件(下单、支付、退款、评价等)。“事实”这个术语表示的是业务事件的度量值(可统计次数、个数、金额等),例如,订单事件中的下单金额。

每一个事实表的行包括:具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

事实表的特征:

  • 非常的大
  • 内容相对的窄:列数较少
  • 经常发生变化,每天会新增加很多。

1)事务型事实表

以每个事务或事件为单位,例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。

2)周期型快照事实表

周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据,例如每天或者每月的销售额,或每月的账户余额等。

3)累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时,事实表的记录也要不断更新。

<think> 我们正在讨论维度表事实表,这是数据仓库中的核心概念。根据用户提供的引用,我们可以系统地介绍这两个概念。 1. 维度表(Dimension Table) - 定义:存储业务过程的描述性信息,提供数据的上下文分类。 - 特征: * 包含多个维度属性(如日期维度表包含年、月、日、季度等属性) * 主键用于关联事实表(通常是代理键) * 行数相对较少(与事实表相比) * 结构相对扁平(通常采用反范式设计) - 作用:为事实表中的度量提供可读性标签,支持数据过滤、分组报表生成。 2. 事实表(Fact Table) - 定义:存储业务过程的量化度量(通常是数值型数据)。 - 特征: * 包含外键(关联维度表度量值(如销售额、数量) * 记录持续增长(随时间推移不断追加新数据) * 体积庞大(通常占数据仓库存储的大部分) - 类型: * 事务事实表(记录原子事件,如每笔交易) * 快照事实表(定期采样,如每日库存) * 累积快照事实表(跟踪过程,如订单生命周期) 3. 两者关系 - 通过外键关联形成星型模式(一对多关系) - 协同工作示例: * 销售事实表包含:[订单ID, 产品ID, 客户ID, 日期ID, 销售额] * 关联维度表:产品维度表(产品名称、类别)、客户维度表(客户地区)、日期维度表(季度、节假日标志) 4. 设计原则 - 维度退化:当维度属性非常少时(如支付方式只有名称),可直接存入事实表避免关联小维度表[^2] - 一致性维度:不同事实表共享的维度表必须保持结构属性一致(如日期维度) 5. 典型结构示例 **日期维度表 (dim_date)** | date_id (PK) | full_date | year | quarter | month | week | day_of_week | is_holiday | |--------------|-----------|------|---------|-------|------|-------------|------------| | 20240101 | 2024-01-01| 2024 | Q1 | 01 | 01 | Monday | 1 (是) | **销售事实表 (fact_sales)** | sale_id | product_id (FK) | date_id (FK) | store_id (FK) | quantity | amount | |---------|-----------------|--------------|---------------|----------|--------| | 1001 | P203 | 20240101 | S07 | 2 | 299.00 | 6. 使用场景对比 | **对比维度** | 事实表 | 维度表 | |---------------|--------------------------------|------------------------------| | **主要用途** | 记录业务事件度量值 | 解释业务事件的上下文 | | **数据特征** | 数值型、可聚合字段 | 描述型、分类字段 | | **数据量** | 大(TB级以上常见) | 小(通常GB级以下) | | **更新频率** | 高频增量(事件驱动) | 低频更新(属性变化时) | | **设计范式** | 通常采用星型模型 | 允许适度冗余(反范式化) | > 注:在星型模型中,维度表不应再关联其他维度表,否则会演变为雪花模型。 7. 技术价值 - 查询优化:维度表的预聚合索引大幅提升分析效率 - 业务语义统一:通过维度表确保不同部门对"客户类型""产品分类"等定义一致 - 历史跟踪:缓慢变化维度技术(SCD)记录属性变更历史[^3] 相关问题: 1. 维度表设计如何解决属性变更问题(SCD技术)? 2. 事实表有哪些类型及适用场景? 3. 星型模型与雪花模型如何选择? 4. 如何优化超大事实表的查询性能? </think> ### 维度表事实表详解 #### 一、核心定义与结构 1. **事实表(Fact Table)** - **本质**:存储业务事件的**量化数据**(如销售额、订单量、日志次数),是数据仓库的**度量中心**[^3]。 - **结构特征**: - 包含**数值型度量值**(如 `sales_amount`, `order_count`) - 通过**外键**关联维度表(如 `product_id`, `time_id`) - 数据量**持续增长**(记录动态业务事件) - **示例结构**: | `order_id` (PK) | `product_id` (FK) | `time_id` (FK) | `sales_amount` | `quantity` | |------------------|-------------------|----------------|----------------|------------| 2. **维度表(Dimension Table)** - **本质**:提供业务事件的**描述性上下文**,是数据的**语义解释层**[^1][^4]。 - **结构特征**: - 包含**分类属性**(如产品名称、日期详情、地区名称) - 主键与事实表外键**一一对应**(如 `product_id`) - 数据量**相对稳定**(属性变化缓慢) - **示例结构**(日期维度表): | `time_id` (PK) | `year` | `quarter` | `month` | `week` | `is_holiday` | |----------------|--------|-----------|---------|--------|--------------| #### 二、核心差异对比 | **维度** | 事实表 | 维度表 | |------------------|---------------------------------|---------------------------------| | **存储内容** | 数值型度量(*What happened?*) | 描述性属性(*How to interpret?*) | | **数据量** | 庞大(TB级+)[^3] | 较小(GB级) | | **更新频率** | 高频追加(事件驱动) | 低频更新(属性变更) | | **主键作用** | 唯一标识事件记录 | 关联事实表的外键 | | **退化场景** | - | 属性少时直接融入事实表[^2] | #### 三、协同关系与建模 1. **关联机制** - **星型模型**:事实表为中心,直接关联所有维度表(高效查询)⭐ ```mermaid graph LR Fact_Sales --> Dim_Product Fact_Sales --> Dim_Time Fact_Sales --> Dim_Location ``` - **雪花模型**:维度表再关联子维度(节省存储,增加复杂度)❄️ 2. **协作示例** - **业务问题**:*“2023年Q3华东地区手机类产品的总销售额”* - **分析路径**: ```sql SELECT SUM(sales_amount) FROM Fact_Sales f JOIN Dim_Time t ON f.time_id = t.time_id -- 时间维度过滤2023Q3 JOIN Dim_Location l ON f.location_id = l.id -- 空间维度过滤华东 JOIN Dim_Product p ON f.product_id = p.id -- 产品维度过滤手机类 ``` #### 四、设计原则 1. **事实表设计要点** - **粒度选择**:存储原子事件(如单笔交易而非月汇总) - **度量优化**:避免文本字段,优先数值型可聚合字段[^4] 2. **维度表设计要点** - **反范式化**:适度冗余提升查询性能(如日期表包含`year/month/day`)[^1] - **一致性维度**:多个事实表共享同一维度表(如全局时间维度)[^2] #### 五、典型应用场景 | **场景** | 事实表作用 | 维度表作用 | |------------------------|-------------------------------|-------------------------------| | 销售分析系统 | 记录每笔交易金额/数量 | 描述产品、门店、促销活动属性 | | 用户行为日志 | 存储点击/停留时长等行为度量 | 定义用户画像、设备类型、页面分类 | | 库存监控 | 跟踪每日库存变化量 | 关联仓库位置、产品SKU详情 | > 示例数据模型: > ``` > 事实表(Fact_Order): [order_id, user_id, product_id, timestamp, amount] > 维度表(Dim_User): [user_id, age, gender, city] -- 解释who > 维度表(Dim_Time): [timestamp, year, month, hour] -- 解释when > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值