![]() |
1
8
通常的工作方式:
基本示例(使用T-SQL)。假设您有以下两个表:
要交换密钥,请执行以下操作:
另一方面,我相信你的设计中有一些错误。
如果您需要更多信息,我推荐这本书: Star Schema The Complete Reference [编辑以回答后续问题]: 我并不是要从索赔维度中删除ClaimNbr字段。我建议您根本不需要这样的维度。 这可能有点难以理解,但请考虑以下几点。“索赔”本质上是一个信息容器(与“发票”、“订单”等相同)。如果您将所有有用的数据块移动到它们的相关维度,那么应该只剩下一个空容器。 例如,假设您的OLTP索赔表包含以下字段:索赔编号、报告期、索赔描述、索赔名称、合同编号、索赔金额。可以按如下方式对其进行建模:
剩下3个字段:索赔编号、索赔名称和索赔描述。此时,一些设计师创建维度“Claim”,并将这些字段停放在那里。正如我前面提到的,这是一个错误,因为这样一来,您的维度中的记录将与事实表中的记录一样多,从而导致严重的问题。 更好的设计是将这些字段保留在事实表中。索赔编号变成了一个“退化维度”——一个“空”(不存在)维度的业务密钥。本质上,它只是一个信息容器的ID,如发票号、订单号等。 索赔名称和索赔描述也应保留在事实表中,并成为“非数字”(非相加)事实。如果您需要在报告中显示它们,这很容易,您可以对它们进行计数,对它们进行条件逻辑,测量它们的长度,等等。 看待这一点的另一种方式是:维度通常用于通过某些属性/字段“分割”(Disct)事实。例如,“按国家划分的销售额”、“按工厂所在地划分的产品成本”等,但你不能按描述、注释或其他自由文本划分,这毫无意义。 如果您的描述或其他索赔属性是结构化的,该怎么办?例如,它们是否用于对您的索赔进行分类?在这种情况下,它们不是自由文本,而是属于维度的属性。例如,您可以设计维度“索赔类型”。或“索赔状态”。等等。如果这些小属性文件太多,可以将它们组合成所谓的“垃圾”维度(也称为“概要文件”维度),即维度“索赔概要文件”。这样的设计既干净又高效。 |