星型模式设计的组成和分析
星型模式设计是在数据仓库中使用的一种数据库模式,旨在提高查询和分析大型数据集的效率。该模式由一个包含待分析数据的中央事实表和一个或多个维度表组成,维度表提供有关事实表中数据的附加信息。
星型模式的组成部分
星型模式由四个主要组件组成。如下所示:
- 事实表
-
维度表
-
属性
-
属性层次结构
让我们逐一介绍它们:
事实
- 这些是货币值。
-
表示业务活动的绩效指标。
-
生产力、成本、销售、利润、定价和数量都是一些例子。
-
事实也被称为测量值。它们保存在事实表中。
文本保存在维度表中,而数值保存在事实表中。数值数字提供了公司业绩的统计指标。与以文本方式描述销售相比,销售统计更易于理解。事实有时也被称为测量值,因为它们用于评估公司的成功。
什么是事实表?
- 详细表是事实表的别名。
-
事实表是星型模式的中心。
-
事实表提供了主键和事实或测量值。
-
事实表由事实和键组成。它们是公司最重要的方面。事实表,通常被称为详细表,显示了业务绩效的概述。它始终位于星型模式的中心或核心位置。它周围是测量表。它还包括事实表的主键。
示例
假设我们有一家零售商店向客户销售产品,并且我们想要在数据仓库中跟踪销售数据。我们可以创建一个名为“销售”的事实表的星型模式,用于跟踪每笔销售的信息。
销售事实表
列名 | 数据类型 | 描述 |
---|---|---|
sale_id | 整数 | 每次销售的唯一标识符 |
customer_id | 整数 | 一个外键,引用顾客维度表 |
product_id | 整数 | 一个外键,引用产品维度表 |
store_id | 整数 | 一个外键,引用店铺维度表 |
sale_date | 日期 | 销售发生的日期 |
quantity | 整数 | 销售的单位数量 |
total_price | 小数 | 销售总价 |
在这个例子中,“销售”事实表包含每次销售的唯一标识符,以及指向顾客、产品和店铺维度表的外键。事实表还包括有关销售日期、销售产品数量和销售总价的信息。该表可用于按顾客、产品、店铺和日期分析销售数据,以及对不同维度的销售数据进行汇总。
事实表的特点
- 事实表定期刷新,插入来自操作数据库的汇总数据。
-
指标是在查询执行过程中计算的事实。
-
每个事实表中都包含维度表。
-
事实表方便数据汇总。
-
至少包含一个事实或测量。
-
主键 – 所有维度表主键的合并。
-
维度表不符合BCNF,但事实表符合。
-
事实表中的一行至少包含一个事实以及其维度表的主键。
-
有三种类型的度量:可加性、半可加性和非可加性。
-
具有少量列和大量行的表,行有点长而且很窄。
-
事实表中单个条目的信息量被称为事实表的粒度。
-
最有价值的事实是数值型、具有恒定值且可加性的事实。
事实表最常见的特征之一是销售额。因此,必须定期更新该值,例如每月或每季度。维度表围绕核心事实表构建星型模式。事实表必须始终包含至少一个事实;否则,它不存在。它不包含替代键;相反,事实表的主键由所有维度表的主键的合并形成。事实表始终处于规范化的BCNF形式。因为事实表包含主键和只有少量事实,所以它的属性较少但行数较多。如果销售数字每天更新一次,则事实表的粒度为一天。
什么是维度表?
- 维度表提供主键和仅用于决策过程的特征。
-
产品维度、位置维度和时间维度是一些例子。
-
主键与外键连接将维度表与事实表连接起来。
-
维度表提供过滤和分组功能。
-
维度通常是描述性数据,也可作为事实数据。
正如名称所示,维度表包含业务实体的支持特征。每个维度表都有一个主键和必需的属性。一种类型的维度表是顾客表。每个维度表通过外键连接与事实表相连。
示例
假设我们有一家零售店向顾客销售产品,并且我们想要在数据仓库中跟踪关于产品的信息。我们可以创建一个星型模式,其中包含一个维表称为“产品”,其中包含有关每个产品的信息−
产品维度表
列名 | 数据类型 | 描述 |
---|---|---|
product_id | 整数 | 每个产品的唯一标识符 |
product_name | 字符 | 产品的名称 |
category | 字符 | 产品所属的类别 |
price | 小数 | 产品的价格 |
supplier_id | 整数 | 一个引用供应商维度表的外键 |
brand_id | 整数 | 一个引用品牌维度表的外键 |
在这个示例中,“products”维度表包含每个产品的唯一标识符,以及有关产品名称、类别、价格和引用供应商和品牌维度表的外键的信息。该表可用于按类别、价格范围、供应商和品牌分析产品信息,以及在不同维度上汇总产品信息。
维度表的特征包括
- 维度表通常被称为查找或引用表。
-
维度表未经过规范化。
-
包含一个主键,该主键是事实表主要键的一部分。
-
维度在时间上不会改变或变化非常缓慢。
-
它们有少量行和大量列。
-
大多数星型模式都包含一个时间维度。
-
维度表之间没有耦合,而是通过PK-FK连接将每个维度表连接到事实表。
-
代理键通常是主键。
这些被称为引用表,因为它们支持事实表中提供的信息。事实表显示了企业实体的摘要,而维度表为事实表提供支持。维度表未经过规范化,因为这样做将导致将维度表拆分为多个表。这将增加模式中的连接数,使星型查询更加困难,执行时间更长。维度表连接到事实表,但不连接到彼此,因为这是不必要的。在每个维度表中引入代理键以唯一标识每个条目。
什么是属性?
- 这些是维度表的列。
-
客户维度表的示例包括客户姓名、年龄、性别、婚姻状况等。
-
这些主要是描述性的值。
列名被称为属性。客户特征是在客户表中适当定义客户的详细信息。客户特征包括他们的姓名、性别、年龄和婚姻状况。通常,它们是描述性数据,如姓名和地址。
假设我们有一家零售店向客户销售产品,并且我们想在数据仓库中跟踪客户信息。我们可以创建一个称为“customers”的维度表,在其中包含有关每个客户的属性-
客户维度表-
列名 | 数据类型 | 描述 |
---|---|---|
customer_id | integer | 每个客户的唯一标识符 |
first_name | varchar | 客户的名字 |
last_name | varchar | 客户的姓氏 |
gender | varchar | 客户的性别 |
date_of_birth | date | 客户的出生日期 |
varchar | 客户的邮箱地址 | |
address | varchar | 客户的街道地址 |
city | varchar | 客户所在的城市 |
state | varchar | 客户所在的州 |
country | varchar | 客户所在的国家 |
在这个例子中,“customers”维度表包含每个客户的唯一标识符,以及客户的姓名、性别、出生日期、电子邮件地址和地址信息等属性。这个表可以用来通过人口统计特征、位置和购买历史来分析客户信息,以及在不同维度上聚合客户信息。
属性层次结构是什么?
- 属性可以按层次组织。
-
层次级别之间有一个N:1的关系。
-
确定了一个功能依赖顺序。
-
示例− 产品->产品类型,产品类型->行业
-
时间维度的层次结构− 日期->周->月->季度->年。
-
位置的层次结构− 城市->区->州->国家->商店
-
属性层次结构用于在多个聚合级别上分析数据,通常从最高级别开始。
-
某些维度表列仅用于描述维度,并未在属性层次结构中使用。
当我们需要更细粒度或更粗粒度的信息时,属性层次结构非常有用。我们可以找到特定季度的整体销售额。如果存在时间层次结构,我们可以检索同一个季度的某个月份的销售额。如果我们在层次结构中进一步,我们可以确定某个月份在某个周内的销售总额。同样地,我们可以沿着结构的方向往上工作。并非所有维度表都需要属性层次结构。
数据聚合的许多方法是什么?
- 数据层次结构由属性层次结构定义。
-
Roll-Up-在层次结构中以更粗的粒度或更高的层次获取数据。
-
Drill-Down-以更细粒度获取数据。
什么是星型查询?
-
星型查询是事实表和多个维度表的连接。
-
这些是非常困难的问题。
-
它需要很长时间来完成。
星型查询是在星型模式上运行的SQL查询。星型查询的名称来自于我们在星型模式上运行查询的事实。由于星型模式在事实和维度列之间有多个连接,因此星型查询很困难。星型查询的执行需要几个小时,因为有多个连接关系。
结论
总之,星形架构设计是数据仓库中对数据进行分析建模的一种高效方法。该架构包括一个中央事实表,其中包含要分析的定量数据,以及一个或多个维度表,提供有关事实表中数据的附加上下文和描述性数据。事实表使用外键链接到维度表,使得可以在不同维度和属性之间执行查询和分析。星形架构设计的分析涉及通过维度表中的各种维度和属性对事实表中的数据进行聚合和查询,以生成提供数据洞察的报告和可视化。使用星形架构设计的好处包括更快的查询性能、简化的数据建模以及对终端用户的易用性。