【发布时间】：2016-05-30 02:21:07
【问题描述】：
给定以下星型模式表。
- 事实，两个维度，两个度量。
# 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
你会如何调用以下架构
它有什么具体的名字吗？星花？ :)
|>-- 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
它基本上有一个维度库表，用于存储维度内每个层次结构的每个级别的身份。无需递归遍历雪花的级别，可能会减少连接。数据仍然很好地规范化，只有键被非规范化到 base 表中。所有层次结构中的所有级别都与维度基数中维度的最低粒度键相关联。
此外，拥有一个维度基础表允许仅在该表中以层次结构级别的粒度处理时间变量属性/时间查询。
这是表格表示。
仍然使用自然键！
- 事实
# 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 两个层次结构的级别都适合时间维度基数 表）。
这样的架构会有什么缺点？我不太关心连接和聚合的速度以及查询工具的适应性。
它有名字吗？正在使用吗？如果不是为什么？
【问题讨论】：
-
> “这种模式有什么缺点？我不太关心连接和聚合的速度，以及查询工具的适应性。”
-
@mef 内存。隔离模型的组件以进行更精确的处理。维度的所有层次结构级别形成了一个无事实事实的维度基础。所有参考数据均已标准化，这意味着可以更快地在报告中重复使用。
-
这个模型只有在你没有聚合表的情况下才有效，否则你需要为每个聚合级别创建一个新的维度关系表，非常烦人并且没有真正的增值
-
@mucio 这对于常规星型模式也是如此，不是吗？因为您实际上并没有存储更高级别的密钥。
-
在星型模式中，您需要一个缩小的维度（可以是带有
distinct的视图）来加入聚合表，在您的情况下，您需要一个额外的连接来获得这个缩小的维度（ How do I get from division to Region? 与基表连接区域表不同，在星型模式中，您只需执行与地理不同的区域）。无论如何，在我看来，您存储了两次相同的信息（在基本和最低层次结构中）；启动模式存储更多数据，但连接更少，雪花更少数据，更多连接。
标签： data-modeling data-warehouse database-normalization star-schema data.cube