星型模式,规范化维度,非规范化层次结构级别密钥

Question

给出以下星型模式表.

• 事实上,两个维度,两个措施.

#   geog_abb  time_date amount     value
#1:       AL 2013-03-26  55.57 9113.3898
#2:       CO 2011-06-28  19.25 9846.6468
#3:       MI 2012-05-15  94.87 4762.5398
#4:       SC 2013-01-22  29.84  649.7681
#5:       ND 2014-12-03  37.05 6419.0224

• 地理维度,单层次结构,层次结构中的3个级别.

#   geog_abb  geog_name geog_division_name geog_region_name
#1:       AK     Alaska            Pacific             West
#2:       AL    Alabama East South Central            South
#3:       AR   Arkansas West South Central            South
#4:       AZ    Arizona           Mountain             West
#5:       CA California            Pacific             West

• 时间维度,两个层次结构,每个层次结构4个级别.

#    time_date time_weekday time_week time_month time_month_name time_quarter time_quarter_name time_year
#1: 2010-01-01       Friday         1          1         January            1                Q1      2010
#2: 2010-01-02     Saturday         1          1         January            1                Q1      2010
#3: 2010-01-03       Sunday         1          1         January            1                Q1      2010
#4: 2010-01-04       Monday         1          1         January            1                Q1      2010
#5: 2010-01-05      Tuesday         1          1         January            1                Q1      2010

示例是剥离代理键以提高可读性.在结果中,层次结构中没有其他属性,只是不要打扰它们,它们仍然是层次结构中的级别.

---

在星型模式中表示为:

         GEOGRAPHY (all fields)
        /
       /
   FACT
       \
        \
         TIME (all fields)

在雪花模式中表示为:

                    geog_region_name
                   /
                  geog_division_name
                 /
                geog_abb (+ geog_name)
               /
              /
          FACT
              \
               \
                time_date
                   |
hierarchies:       |
        weekly    / \    monthly
                 /   \ 
                /     \
   time_weekday         time_month (+ time_month_name)
            |             |
            |             |
        time_week     time_quarter (+ time_quarter_name)
            |             |
            |             |
        time_year      time_year

您将如何调用以下架构

它有什么具体的名字吗？Starflake？:)

        |>-- geog_region_name
        |
        |>-- geog_division_name
        |
        |>-- geog_abb (+ geog_name)
        |
        |
        geography base
       /
      /
  FACT
      \
       \
        time base
        |
        |
        |>-- time_date
        |
        |>-- time_weekday
        |
        |>-- time_week
        |
        |>-- time_month (+ time_month_name)
        |
        |>-- time_quarter (+ time_quarter_name)
        |
        |>-- time_year

它基本上有一个维度基表,用于存储维度中每个层次结构的每个级别的标识.不需要递归遍历雪花的级别,可能更少的连接.数据仍然很好地规范化,只有键被非规范化为基表.所有层次结构中的所有级别都与维度库中维度的最低粒度键相关联.
另外,具有维度基表允许以层次结构级别的粒度处理该表中的时间变量属性/时间查询.

这是表格表示.

仍然在自然键!

• 事实

#    geog_abb  time_date amount     value
# 1:       AK 2010-01-01 154.43 12395.472
# 2:       AK 2010-01-02  88.89  6257.639
# 3:       AK 2010-01-03  81.74  7193.075
# 4:       AK 2010-01-04 165.87 11150.619
# 5:       AK 2010-01-05   8.75  6953.055

• 时间维度基础

#     time_date time_year time_quarter time_month time_week time_weekday
# 1: 2010-01-01      2010            1          1         1       Friday
# 2: 2010-01-02      2010            1          1         1     Saturday
# 3: 2010-01-03      2010            1          1         1       Sunday
# 4: 2010-01-04      2010            1          1         1       Monday
# 5: 2010-01-05      2010            1          1         1      Tuesday

• 时间维度规范化到层次结构级别

#    time_year
# 1:      2010
# 2:      2011
# 3:      2012
# 4:      2013
# 5:      2014

#    time_quarter time_quarter_name
# 1:            1                Q1
# 2:            2                Q2
# 3:            3                Q3
# 4:            4                Q4

#    time_month time_month_name
# 1:          1         January
# 2:          2        February
# 3:          3           March
# 4:          4           April
# 5:          5             May

#    time_week
# 1:         1
# 2:         2
# 3:         3
# 4:         4
# 5:         5

#    time_weekday
# 1:       Friday
# 2:       Monday
# 3:     Saturday
# 4:       Sunday
# 5:     Thursday

#     time_date time_week time_weekday time_year
# 1: 2010-01-01         1       Friday      2010
# 2: 2010-01-02         1     Saturday      2010
# 3: 2010-01-03         1       Sunday      2010
# 4: 2010-01-04         1       Monday      2010
# 5: 2010-01-05         1      Tuesday      2010

• 地理维度基础

#    geog_abb geog_region_name geog_division_name
# 1:       AK             West            Pacific
# 2:       AL            South East South Central
# 3:       AR            South West South Central
# 4:       AZ             West           Mountain
# 5:       CA             West            Pacific

• 地理维度规范化到层次结构级别

#    geog_region_name
# 1:    North Central
# 2:        Northeast
# 3:            South
# 4:             West

#    geog_division_name
# 1: East North Central
# 2: East South Central
# 3:    Middle Atlantic
# 4:           Mountain
# 5:        New England

#    geog_abb  geog_name geog_division_name geog_region_name
# 1:       AK     Alaska            Pacific             West
# 2:       AL    Alabama East South Central            South
# 3:       AR   Arkansas West South Central            South
# 4:       AZ    Arizona           Mountain             West
# 5:       CA California            Pacific             West

维度库也可以存储主键的属性,这将减少维度的最低级别,但不太一致(time_date两个层次结构的级别将适合时间维度基表).

---

这种架构会有什么缺点？我不太关心连接和聚合的速度,以及查询工具的适应性.
它有什么名字吗？它正在使用？如果不是为什么？

Answer 1

您正在使用快捷方式构建雪花模式。

使用它和BI工具可以轻松使用快捷方式。

您还可以使用从维度的父级别到该维度的子级别的事实表的快捷方式。它有效，您可以跳过联接，但您需要在事实表中存储附加列。

唯一关心的是数据完整性，如果父子关系发生更改，您不仅需要更新子表，还需要更新存储此关系的所有其他表。

如果每次都从规范化数据生成维度表，这没什么大不了的，但您需要小心，如果您在事实表中存储父 ID，则更要小心。

Answer 2

您正在做的不是雪花模式......它类似于“Data Vault”和我们自己的变体“Link-Model”。它本质上创建仅包含事实表和 Dim 表（以及其他 Dim 表）之间的键的链接表。尽管如此，我们将它们描述为实体表和度量表。

优点是

• 您可以并行加载维度和事实表，然后填充链接表
• 复杂的做法，例如保险中的“报告时”和“调整”，可以很容易地处理
• 分割慢速变化维度和快速变化维度只是通过链接表链接起来的维度表更加直观。这样可以节省时间。
• 向事实表添加新维度相当简单快捷，毕竟它只是向仅包含整数的表添加一个额外的整数列。
• 无事实的事实比传统模式更加直观。您可以在维度之间创建关系，而无需任何事实记录。

缺点是

• 模式结构稍微复杂一些，因此我们通常在“链接模型”之上创建 Kimball 模型，因为业务用户往往会很好地理解它。
• 向事实表添加新维度或扩展维度表可以轻松完成，但随着时间的推移，架构可能会变得混乱。