1

我有一个星型模式仓库（MS SQL Server，通过带有 OLAP 的 MS Report Builder 访问），它有很多微小的维度——我的意思是维度是由两列（Id 和 Description）构建的，其中有数百个从 Fact 链接表。

这提供了在没有实际计数的情况下显示所有项目的选项。非规范化表的描述是事实的一部分，因为这将提供更好的能力来通过 SQL 和 OLAP 方法查询数据。

这种包含许多一级维度的结构是否正常且良好的做法？老实说，唯一一次我希望显示空白是针对诸如时间或日期维度之类的东西，但是由于这些可以从数据中强制为您提供图表和表格中的空白，因此它似乎并没有那么重要.

关于这种结构是好是坏的任何看法——我想尝试改变它，但如果我与最佳实践脱节，我会很乐意改变我的心态。

结构示例（这只是一个事实表的一部分）

事实表 - （属性）

F_PROPERTY.PROPERTY_ID (Key for table)
F_PROPERTY.CYCLE_FRAME_TYPE_ID
F_PROPERTY.CYCLE_GEARS_NUMBER_ID
F_PROPERTY.CYCLE_GEARS_TYPE_ID
F_PROPERTY.CYCLE_GENDER_ID
F_PROPERTY.CYCLE_MUD_GUARDS_ID
F_PROPERTY.CYCLE_MUD_GUARDS_COLOUR_ID

维度表 -

D_CYCLE_FRAME_TYPES.CYCLE_FRAME_TYPE_ID
D_CYCLE_FRAME_TYPES.CYCLE_FRAME_TYPE_DESC

D_CYCLE_GEAR_TYPES.CYCLE_GEAR_TYPE_ID
D_CYCLE_GEAR_TYPES.CYCLE_GEAR_TYPE_DESC

D_CYCLE_GEAR_TYPES.CYCLE_GEARS_NUMBER_ID
D_CYCLE_GEAR_TYPES.CYCLE_GEARS_NUMBER_DESC

D_CYCLE_GEAR_TYPES.CYCLE_GENDERS_ID
D_CYCLE_GEAR_TYPES.CYCLE_GENDERS_DESC

D_CYCLE_GEAR_TYPES.CYCLE_MUD_GUARDS_ID
D_CYCLE_GEAR_TYPES.CYCLE_MUD_GUARDS_DESC

所以换个说法 - 维度真的应该是事实的单独表格，还是将描述作为事实的一部分更好？我希望报告快速而简单，并且在字段中没有值的情况下删除记录最少。

4

1 回答 1

2

不要将描述放在事实表中。事实的目的是衡量事件。维度显示事件的可能属性，即使事件尚未发生。餐厅菜单将是一个维度，客户订购的食物是事实事件。

看起来您可能需要对尺寸进行非规范化。例如，如果您的自行车齿轮具有类型、编号和制造商，则将其设为具有一个 ID 和三个描述属性的单个自行车齿轮尺寸。

您还应该考虑垃圾尺寸。这些是由多个不相关的单一属性维度组成的，实际上结合使用一个 ID。记录数是所有可能的列属性的笛卡尔积，但您可以通过消除不切实际的组合来减少其中一些。例如，性别、种族和教育将是单一垃圾维度的良好候选者。它们不相关，但值很少，因此笛卡尔积是合理的。

Star Schema 通过过滤较小的唯一维度属性然后加入事实事件来实现非常高性能的报告查询。混淆事实表会降低整体性能。

于 2017-05-26T16:19:37.850 回答