关于设计星型模式:我在事实表中有三个日期列fact_table (insert_date, trade_date, close_date ...)
。而且我不知道应该创建多少个日期维度?
案例 1:昏暗 A 。这意味着:一行@fact_table 有三个 FK 到 A。
情况 2:Dim A(用于 insert_date)、Dim B(trade_date)、Dim C(close_date)。这意味着:一行@fact_table 有一个 FK 到 A,一个 FK 到 B,一个 FK 到 C。
问题:应该创建多少个日期维度?
Yas*_*IDI 10
维度表示一类信息:例如日期、产品...在您的情况下,事实表中有三个属性引用同一分析轴“日期”,因此如果您使用星型模式,则只有一个日期维度需要,这是一个维度角色扮演实现。
有两个维度的角色扮演实现:
该表的别名类型通过分配每次使用一个别名使用了尺寸比曾经在一个SQL语句更多。
该数据库视图类型,您创建的,因为你需要的事实维度角色的数量很多意见。
您只需要一个日期维度,例如:
日期维度的“类型”将在上面的事实表中提到。
更新 :
建模日期和时间维度
在所有事实和维度表中应该只有一个日期维度和一个时间维度。并非所有日期和时间字段都需要映射到日期和时间维度。仅当您需要维度中的额外属性时,才将日期时间字段映射到日期或时间维度。
通常,Date 维度的最低粒度为Day,Time 维度的最低粒度为Second。许多仓库不需要时间维度,但几乎每个数据仓库系统都使用日期维度。
通常,为日期和时间创建单独的维度。
如果有必要提取跨越日边界的连续时间块(例如11/24/2000 10 p.m. to 11/25/2000 6 a.m.
),那么如果小时和天在同一维度上会更容易。否则,将Date
和 的单独维度Time
更易于管理和查询。
如果日期和时间是单独的维度,则更容易分析周期性和重复发生的日常事件。
示例:
本周上午 9 点进行的会议数量。如果日期和时间是分开的,这是一个简单的查询;如果将日期和时间合并为一个维度,则复杂得多。以下是将日期和时间维度放在一个日期/时间维度中的问题:
问题#1:
- 将日期和时间合并到一个维度中会创建一个非常大的维度,尤其是当您使用秒作为粒度时。如果您使用 Hour 作为组合表的粒度,问题就没有那么大了。
- Cardinality of Date and Time Dimensions (separated) for 10 years of data Date Dimension: 10 * 365 = 3650 Time Dimension (granularity:
seconds): 24 * 60 * 60 = 86400- Cardinality of Date and Time Dimensions (combined) for 10 years of data DateTime Dimensions (granularity Hourly): 10 * 365 * 24 = 87600
DateTime Dimensions (granularity Seconds): 10 * 365 * 24 * 60 * 60 =
315,360
DateTime 维度中的记录越多,查询性能就越慢。
问题 #2
在同一维度中同时具有日期和时间维度可能会导致具有一天粒度的事实表的解释问题。由于维度表中的额外粒度,很容易在同一天无意中将两条记录输入到事实表中。
查找更多:来源
归档时间: |
|
查看次数: |
11462 次 |
最近记录: |