什么是 BI 系统里的 Star Schema
星型架构 (Star Schema) 是数据仓库和商业智能 (BI) 领域中广泛采用的一种数据模型。它的名字来源于其结构的视觉效果，中心的事实表和周围的维度表形成类似星星的形状。
这个架构的核心元素包括事实表（Fact Table）和一系列维度表（Dimension Tables）。事实表保存的是业务事件或事务的度量（比如销售金额、销售数量），而它的外键指向相关的维度表。维度表包含的是业务对象的属性信息（比如产品、时间、客户等）。
为了更好地理解星型架构，我们可以联想到一个大型零售商店的销售数据分析系统。
真实世界的例子：零售商店销售数据分析
事实表：Sales_Fact
零售商店每天会有大量的销售数据，这些数据需要被记录和分析。假设我们有这样一个事实表 Sales_Fact，记录每一笔销售的具体信息。
| Sale_ID | Product_ID | Customer_ID | Time_ID | Sales_Amount | Quantity_Sold |
|---|---|---|---|---|---|
| 1 | 101 | 2001 | 202101 | 100.00 | 2 |
| 2 | 105 | 2002 | 202102 | 150.00 | 1 |
| 3 | 101 | 2003 | 202103 | 200.00 | 4 |
每一行记录一笔具体的销售交易。其中 Product_ID、Customer_ID 和 Time_ID 是外键，分别指向产品表、客户表和时间表。
维度表：Product_Dimension, Customer_Dimension, Time_Dimension
维度表存储的是关于产品、客户和时间的详细信息。
Product_Dimension
| Product_ID | Product_Name | Category | Price |
|---|---|---|---|
| 101 | Widget_A | Electronics | 50.00 |
| 105 | Widget_B | Toys | 150.00 |
Customer_Dimension
| Customer_ID | Customer_Name | Region | Age_Group |
|---|---|---|---|
| 2001 | Alice | North | 25-34 |
| 2002 | Bob | East | 35-44 |
Time_Dimension
| Time_ID | Year | Month | Day |
|---|---|---|---|
| 202101 | 2021 | 01 | 01 |
| 202102 | 2021 | 02 | 01 |
在这个例子中，Sales_Fact 表中记录的每一笔销售的具体信息包括销售的产品、销售的时间和购买的客户，而这些信息通过外键关联到相关的维度表 Product_Dimension、Customer_Dimension 和 Time_Dimension 中。
使用星型架构的好处
这个架构的主要优点在于其设计相对简单、查询性能优异及易于理解和使用。查询性能的提升主要归功于维度表的去归纳化（denormalization），这意味着每个维度表独立存在，而不是与更多表连接，从而减少了查询的复杂度和执行时间。
案例研究：大型超市的销售分析系统
接下来，我们以一个更复杂的大型超市为例，探讨星型架构在实际应用中的细节和优势。
问题背景
大润发是一家大型连锁超市，它既在国内有广泛的门店网络，也有电商平台业务。公司希望通过数据仓库系统分析其每天、每周、每月的销售情况，找到销售规律以及顾客行为模式，从而制定更有针对性的营销策略。
数据需求
为了实现全面的销售分析，大润发需要记录的销售数据包括：
- 每笔交易涉及的具体产品。
- 交易发生的时间。
- 购买商品的客户信息。
- 每笔交易的金额和数量。
- 销售发生的门店或者是电商平台。
设计架构
基于上述数据需求，我们可以设计一个星型架构的数据仓库来满足查询和分析需求。
事实表：Sales_Fact
| Sale_ID | Product_ID | Customer_ID | Time_ID | Store_ID | Channel_ID | Sales_Amount | Quantity_Sold |
|---|---|---|---|---|---|---|---|
| 1 | 101 | 2001 | 202101 | 3001 | 4001 | 100.00 | 2 |
| 2 | 105 | 2002 | 202102 | 3002 | 4002 | 150.00 | 1 |
维度表：Product_Dimension
| Product_ID | Product_Name | Category | Price |
|---|---|---|---|
| 101 | Widget_A | Electronics | 50.00 |
| 105 | Widget_B | Toys | 150.00 |
维度表：Customer_Dimension
| Customer_ID | Customer_Name | Region | Age_Group |
|---|---|---|---|
| 2001 | Alice | North | 25-34 |
| 2002 | Bob | East | 35-44 |
维度表：Time_Dimension
| Time_ID | Year | Month | Day |
|---|---|---|---|
| 202101 | 2021 | 01 | 01 |
| 202102 | 2021 | 02 | 01 |
维度表：Store_Dimension
| Store_ID | Store_Name | Location | Size |
|---|---|---|---|
| 3001 | Store_A | City_Center | Large |
| 3002 | Store_B | Suburb | Medium |
维度表：Channel_Dimension
| Channel_ID | Channel_Name |
|---|---|
| 4001 | In-Store |
| 4002 | Online |
通过这样的设计，每一笔销售交易都能被具体地分类和分析。分析人员可以通过查询 Sales_Fact 表与各种维度表进行连接，提取和分析各种维度的信息。例如，他们可以轻松地分析出某个地区某类商品在特定月份的销售情况。
查询示例
例如，营销团队想知道 2021 年 1 月份所有电子产品在北方地区的销售额和销售数量。可以使用如下 SQL 语句实现：
SELECT SUM(Sales_Amount) AS Total_Sales, SUM(Quantity_Sold) AS Total_Quantity
FROM Sales_Fact
JOIN Product_Dimension ON Sales_Fact.Product_ID = Product_Dimension.Product_ID
JOIN Customer_Dimension ON Sales_Fact.Customer_ID = Customer_Dimension.Customer_ID
JOIN Time_Dimension ON Sales_Fact.Time_ID = Time_Dimension.Time_ID
WHERE Time_Dimension.Year = 2021
AND Time_Dimension.Month = 1
AND Product_Dimension.Category = `Electronics`
AND Customer_Dimension.Region = `North`;
这样的查询能够快速返回结果，而无需额外复杂的连接操作。
总结和展望
星型架构之所以被广泛采用，是因为它在处理和查询大规模数据时效率高且易于理解。通过一个中心的事实表和多个维度表，用户可以快速、灵活地进行各种商业分析。
在未来，随着数据量的增长和分析需求的多样化，星型架构还有可能进一步演化。例如，一些企业开始结合雪花架构（Snowflake Schema），即在一定程度上增加维度表的规范化，以便在数据极其庞大和多样化时，提高存储效率和复杂查询的性能。
总的来说，掌握和运用星型架构，不仅是数据工程师和商业分析师的基本技能，也将在企业数据驱动决策中发挥重要作用。无论是零售企业的大规模销售数据分析，还是其他行业的业务数据处理，星型架构都提供了可靠、高效的解决方案。通过不断优化和探索，我们可以利用星型架构，更好地挖掘数据的价值，驱动企业业务的持续增长和改善。
- 点赞
- 收藏
- 关注作者
评论（0）