为什么要在星型模式中使用代理键和渐变维度？

代理键是关系表中行/记录的唯一标识符。它被添加到不包含单个唯一列的每个维度表中以支持星形建模。维度表中的代理键示例：

Dimension: Customer
Attributes:
Customer_id (Primary key and surrogate key)
Name
Age
Gender
Address
Email
Marital Status
city

这里，“Customer_id”是代理键。它不是关于单个客户的有用信息，而是在存储在数据库中时为每个单个客户提供唯一标识。

在星型模式中使用代理键：

业务密钥在 OLTP 系统中通常具有业务含义，例如员工的社会安全号码。因此，这些与业务设置和要求相关。如果这种类型的业务键发生变化，那么所有使用这些业务键的表也需要更新。因此，我们避免了这个问题，只为每个维度表添加代理键。代理键只是唯一的整数，永远不必更改。
与代理键相比，业务键的大小通常更大，这会导致索引变大并减慢索引遍历，从而增加查询执行时间。因此，为了使它们更高效、更快的系统，我们避免使用业务密钥，而是使用代理密钥。
业务密钥通常会在较长时间内重复使用。因此，相同的业务键不会唯一标识表中的记录。
代理键也可以成功地用于处理缓慢变化的维度。

因此，我们不使用唯一的业务键作为主键。我们更喜欢代理键作为每个维度表中的主键。

渐变尺寸（SCD）：

这些是随时间缓慢变化的维度表的属性，既不频繁也不周期性。
SCD 包含当前和历史数据。
客户的婚姻状况、电子邮件和客户的手机号码。

在 OLTP 系统中，允许覆盖记录。但是在数据仓库系统中，历史数据被存储用于分析目的。所以，这个数据不能被覆盖。

SCD的类型：

Type-1 SCD：在 Type-1 SCD 中允许覆盖。在这里，新数据会覆盖现有数据。现有数据会丢失，并且不会存储在其他任何地方。这是我们创建的默认维度类型。无需指定任何其他信息来创建它们。示例：客户维度的电子邮件和 Marital_status。婚姻状况不会经常变化。它会随着时间的推移而非常缓慢地变化一次或两次。

坏处：

维度将始终包含每个属性的当前值，并且历史数据会丢失。

Type-2 SCD：创建另一个维度记录。它保留了价值的全部历史。当所选属性的值发生变化时，当前记录将关闭。使用更改的数据值创建一条新记录，该新记录成为当前记录。每条记录都包含有效时间和到期时间，以标识记录处于活动状态的时间段。应该向维度表添加三个额外的列： 1. Start_Date。 2. End_Date，3. Active_Flag。示例：员工维度表的薪水。如果工资随时间变化，则不会被覆盖，而是将活动时间段添加到旧工资信息中。

Type-3 SCD：创建当前值字段。为某些选定的级别属性存储两个版本的值。每条记录存储所选属性的先前值和当前值。当任何选定属性的值发生变化时，当前值存储在 previous_column 中，新值存储在 current_value_column 中。示例：客户维度的城市。如果客户随着时间的推移改变了他的城市，那么我们既不会覆盖城市名称，也不会为此保留活动标志。我们只需创建两行，说明什么是旧城，什么是新城。

Note: 
SCD-1 approach is commonly used for supplementary columns such as email id, 
mobile number of customers.
SCD-2 is not a good approach for Rapidly Changing Dimensions. 
Hence, separate rapidly changing attributes by implementing junk dimensions.

垃圾维度：垃圾维度可以定义为存储垃圾属性的地方。与任何特定维度无关的随机事务代码、标志等的集合。交付、发货、接收、包装和退回等属性可以具有指示标志，如是/否、是/否、真/假。它减小了事实表的大小。

Factless table：不包含任何事实或度量的事实表。它仅包含其维度表中的主键。它用于解决多对多基数问题。