我有一个星型模式仓库（MS SQL Server，通过带有OLAP的MS Report Builder访问），它有很多小尺寸 - 我的意思是尺寸是由两列（Id和Description）构建的，有几百个链接来自Fact表。
这提供了即使没有针对此回报的实际计数而显示所有项目的选项（显示空值），但是我不相信这代表了最佳方式的数据 - 我宁愿看到少量非规范化表，其中描述是事实的一部分，因为这将提供更好的通过SQL与OLAP方法一起查询数据的能力。
许多一级维度的结构是否正常且良好实践？说实话，我唯一希望显示空白的时间是针对某些时间或日期维度，但是因为这些可以从数据中强制给出图表和表格中的空白，所以它似乎并不重要。
关于这种结构是好还是坏的任何观点 - 我想尝试改变这一点，但如果我与最佳实践不合适，我会很乐意改变我的心态。
结构示例（这只是一个Fact表的一部分）
事实表 - （财产）
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
如此改写这一点 - 维度是否真的应该是事实的单独表格，还是作为事实的一部分，它们会更好？我希望报告快速而简单，并且在字段中没有值的记录丢失最少。
答案 0 :(得分：1)
不要将描述放在事实表中。事实的目的是衡量事件。尺寸显示事件的可能属性，即使事件未发生也是如此。餐馆菜单是一个维度，顾客订购的食物是事实。
看起来您可能需要对尺寸进行反规范化。例如，如果您的自行车用具有类型，编号和数字。制造商，使其具有一个ID和三个描述属性的单循环齿轮尺寸。
您还应该考虑垃圾尺寸。它们由多个不相关的单个属性维度组成，组合在一起使用一个ID。记录数是所有可能列属性的笛卡尔积，但您可以通过消除不切实际的组合来减少这些属性。例如，性别，种族和教育将是单一垃圾级别的良好候选者。它们是无关的，但价值很少，所以笛卡尔积很合理。
Star Schema通过过滤较小的唯一维度属性，然后加入事实事件，实现了非常高性能的报告查询。混淆事实表将降低整体性能。