1. 概述编辑
本文提供一些数据表基本概念。
在维度模型中，维度表描述与业务和分析要求相关的实体。 大致而言，维度表代表你建模的内容。 内容可以是产品、人员、地点或任何其他概念，包括日期和时间。 若要轻松识别维度表，通常要为其名称加上前缀 d_ 或 Dim_。
2. 维度表结构编辑
示例给出一个销售人员维度表，如下图所示：
代理键
定义： 代理键是一种由数据仓库系统自动生成的唯一标识符，用于识别维度表中的每一行记录。
作用：
稳定性： 代理键的值是由系统分配的，不受业务变化的影响，因此更为稳定。
性能优势： 由于代理键是递增或随机生成的数字，对于数据库索引的性能有积极影响，提高了查询效率。
优势：
灵活性： 允许系统独立管理唯一标识，降低了与业务变化相关的复杂性。
易维护性： 由于代理键不受外部业务数据的影响，维护起来更加简便。
适用场景：
维度表： 通常在维度表中使用代理键，用于唯一标识每个维度记录。
关联： 在与事实表建立关联时，作为连接点，提供更高效的关联操作。
示例中的 Salesperson_SK 表示代理键。
自然键
自然键是维度模型中的一个关键概念，与代理键相对。自然键使用数据本身的业务属性作为标识符，其在维度表中用于唯一地标识记录。以下是自然键的主要特点：
定义：自然键是由维度表中现有的业务数据属性构成的标识符，用于唯一标识每个维度记录。
作用：
业务关联： 自然键直接反映真实业务世界中的关系，与业务实体的属性相对应。
可读性： 自然键通常具有业务含义，使得数据更易理解，有助于业务用户的可读性。
优势：
业务可理解性： 由于自然键基于现有数据，更容易为业务人员理解和使用。
反映真实业务： 自然键直接映射到业务实体，提供了更直观的数据模型。
限制：
不稳定性： 部分情况下，自然键可能受到业务变化的影响，导致不稳定性。
复杂性： 在处理变化、合并或分割等业务操作时，自然键可能引入复杂性。
适用场景：
业务明确： 当业务实体有清晰的、稳定的业务标识时，自然键是一个合适的选择。
用户可理解： 当用户更容易通过业务属性识别记录时，自然键有助于提高可理解性。
示例中的 EmployeeID 表示自然键。
外键
其他维度表可以引用外键，并且它们存在于维度表中是一种特殊情况。 它表示该表与另一个维度表相关。
示例中的 SalesRegion_FK 表示外键。
维度属性
示例维度表还具有维度属性，如 FirstName 列。 维度属性为存储在相关事实数据表中的数值数据提供上下文。 它们通常是分析查询中使用的文本列，用于筛选和分组，但不能自行合并。 一些维度表包含少数几个属性，而另一些则包含许多属性。
历史跟踪属性
历史跟踪属性是可选的，取决于跟踪源系统中发生的特定更改的需要。 它们使存储值能够支持数据仓库的主要角色，即准确描述过去。 具体而言，当 ETL 进程将新的或更改的数据加载到维度时，这些属性将存储历史上下文。
审核属性
审核属性是可选的，但建议使用。 它们使你能够跟踪创建或修改维度记录的时间和方式，并且可以包括 ETL 进程中产生的诊断或故障排除信息。 例如，将要跟踪谁（或哪些进程）更新了行，以及何时进行的更新。 审核属性还可以帮助诊断具有挑战性的问题，例如 ETL 进程何时意外停止。
3. 维度表大小
通常，维度模型中最有用且最通用的维度是大而宽的维度。维度支持对事实数据进行所需的筛选、分组和准确的历史分析。
大维度可能源自多个源系统。 在这种情况下，维度处理需要组合、合并、删除重复数据并标准化数据：以及分配代理键。
相比之下有些维度很小。 可能表示只包含几个记录和属性的查找表。 通常这些小维度存储与事实数据表中的事务相关的类别值，以具有代理键的维度形式实现，以与事实记录相关。
4. 维度设计概念编辑
层次结构
通常，维度列会生成层次结构。 层次结构允许在不同的汇总级别浏览数据。 例如，初始视图可能显示年销售额，报表使用者可以选择钻取以显示季度和每月销售额。
可通过三种方法将层次结构存储在维度中。 可用工具如下：
来自单个非规范化维度的列。
Snowflake 维度，其中包含多个相关表。
维度中的父-子关系（自引用）。
均衡层次结构
均衡层次结构是最常见的层次结构类型。 均衡层次结构具有相同的级别数。 均衡层次结构的一个常见示例是日期维度中的日历层次结构，该层次结构包含年份、季度、月和日期的级别。
例如门店区域的均衡层次结构可以包括两个级别，即省份、城市。
均衡层次结构的级别基于来自单个非规范化维度的列，或基于构成 Snowflake 维度的表。 当基于单个非规范化维度时，表示较高级别的列包含冗余数据。
对于均衡层次结构，事实数据始终与层次结构的单个级别相关，这通常是最低级别。 事实数据就可以合并（汇总）到最高级别的层次结构。 事实数据可以与任何级别相关，这由事实数据表的粒度决定。 例如，销售事实数据表可能以日期级别存储，而销售目标事实数据表可能以季度级别存储。
非均衡层次结构
非均衡层次结构是一种不太常见的层次结构类型。 非均衡层次结构具有基于父-子关系的级别。 非均衡层次结构中的级别数由维度行决定，而不是特定的维度表列。
非均衡层次结构的一个常见示例是员工层次结构，其中员工维度中的每一行都与同一表中的报表管理器行相关。 在这种情况下，任何员工都可以成为具有报告员工的经理。 当然，层次结构的一些分支将比其他分支具有更多的级别。
下图描绘了一个非均衡层次结构。 它包括四个级别，层次结构中的每个成员都是销售员。 请注意，销售员在层次结构中的上级数不同，具体取决于他们向谁报告。
非均衡层次结构的其他常见示例包括物料清单、公司所有权模型和总帐。
对于非均衡层次结构，事实数据始终与维度粒度相关。 例如，销售事实数据与具有不同报告结构的不同销售员相关。 维度表将具有代理键（命名为 Salesperson_SK）和 ReportsTo_Salesperson_FK 外键列，其引用了主键列。 每个没有人要管理的销售员不一定在层次结构任何分支的最底层。 当他们不处于最低级别时，销售员可能会销售产品，并且还会具有也在销售产品的报告销售员。 因此，事实数据的汇总必须考虑各个销售员及其所有下级。
查询父-子层次结构可能很复杂和缓慢，尤其是对于大维度。 虽然源系统可能会将关系存储为父-子级，但建议将层次结构自然化。 在此实例中，自然化意味着将层次结构级别转换和存储到维度中作为列。
不规则层次结构
有时层次结构是不规则的，因为层次结构中的成员的父级存在于不紧随其上方的级别。 在这些情况下，缺失的级别值会重复父级的值。
请考虑均衡的地理层次结构的示例。 当国家/地区没有州或省时，存在不规则分级结构。 例如，新西兰既没有州也没有省。 因此，插入新西兰行时，还应将国家/地区值存储在 StateProvince 列中。
日历和时间
事实数据表几乎无一例外地存储特定时间点的度量值。 若要支持按日期（可能是时间）进行分析，必须有日历（日期和时间）维度。
源系统具有日历维度数据并不常见，因此必须在数据仓库中生成它。 通常，它只生成一次，如果它是日历维度，则在需要时可以使用将来日期对其进行扩展。
日期维度
日期（或日历）维度是用于分析的最常见维度。 它为每个日期存储一个行，并支持按特定日期周期（如年份、季度或月份）进行筛选或分组的常见要求。
日期维度不应该包含扩展到一天中的时间的粒度。 如果需要一天中的具体时间分析，则应同时具有日期维度和时间维度。 存储一天中的具体时间事实数据的事实数据表应有两个外键，每个外键对应一个维度。
日期维度的自然键应使用日期数据类型。 代理键应使用 YYYYMMDD 格式和 int 数据类型来存储日期。 当代理键值具有意义且人工可读时，此接受的做法应该是唯一的例外（与时间维度一起）。 以 YYYYMMDD 数据类型存储。
当维度用于与更高粒度的事实数据关联时，事实数据表可以使用日期周期的第一个日期。 例如，存储季度销售员目标的销售目标事实数据表会将季度的第一个日期存储在日期维度中。 另一种方法是在日期表中创建键列。
维度应该用所有事实数据表使用的已知日期范围填充。 它还应包括数据仓库存储有关目标、预算或预测的事实数据时的将来日期。 与其他维度一样的是，可以包含表示缺失、未知、N/A 或错误情况的行。
时间维度
事实数据需要存储在某个时间点（如一天中的具体时间）。 在这种情况下，创建时间（或时钟）维度。 它可以有分钟（24 x 60 = 1,440 行）甚至是秒（24 x 60 x 60 = 86,400 行）的粒度。 其他可能的粒度包括半小时或一小时。
时间维度的自然键应使用时间数据类型。 代理键可以使用适当的格式，并存储具有意义且人工可读的值，例如，通过使用 HHMM 或 HHMMSS 格式。
子维度
当某个维度表与其他维度表相关时，它被称为子维度。 子维度有助于符合和重复使用维度模型中的定义。
例如，你可以创建一个地理维度，用于存储每个邮政编码的地理位置。 然后，客户维度和销售员维度可以引用该维度，它们将存储地理维度的代理键。 这样，就可以使用一致的地理位置对客户和销售员进行分析。
多值维度
当某个维度属性必须存储多个值时，需要设计多值维度。 通过创建网桥表（有时称为联接表）来实现多值维度。 网桥表存储实体之间的多对多关系。
例如，假设有一个销售员维度，并且每个销售员都分配给一个或多个销售区域。 在这种情况下，创建销售区域维度是有意义的。 该维度只将每个销售区域存储一次。 一个单独的表（称为网桥表）为每个销售员和销售区域关系存储一行。 从物理上看，销售员维度到网桥表之间存在一对多关系，销售区域维度与网桥表之间存在另一个一对多关系。 从逻辑上看，销售员与销售区域之间存在多对多关系。
在下图中，Account 维度表与 Transaction 事实数据表相关。 由于客户可以有多个帐户，并且帐户可以有多个客户，因此维度表通过 Customer 网桥表关联。
退化维度
当维度与相关事实数据的粒度相同时，可能会发生退化维度。 退化维度的常见示例是与销售事实数据表相关的销售订单号维度。 不复制此数据来创建单独的维度表是可接受的做法。
下面的关系图描绘了 Sales_Order 维度，它是基于销售事实数据表中的 SalesOrderNumber 列的退化维度。
角色扮演维度
在当一个维度在事实数据表中被多次引用时，称为角色扮演维度。
例如，当销售事实数据表具有订单日期、装运日期和交付日期维度键时，日期维度以三种方式关联。 每个方式都表示不同的角色，但只有一个实际日期维度。
下面的关系图描绘了事实数据表。 销售维度是角色扮演维度，因为它作为机会销售维度和签单销售维度与事实数据表有两次关联。
