使用“事实” “维度使用”上的关系类型SSAS OLAP 多维数据集中的选项卡

发布于 2024-12-14 08:14:55 字数 81 浏览 7 评论 0原文

我希望有人能够解释“维度使用”选项卡下“事实关系类型”的适当使用。是否只是从事实表中创建一个维度来访问事实表本身的属性?

提前致谢!

I was hoping someone could explain the appropriate use of the 'FACT Relationship Type' under the Dimension Usage tab. Is it simply to create a dimension out of your fact table to access attribute on the fact table itself?

Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

心的憧憬 2024-12-21 08:14:55

是的,如果您的事实表具有您想要进行切片(从中创建维度)的属性,您将使用此关系类型。

从功能上来说,对于用户来说,它的行为与常规关系没有什么不同。

Yes, if your fact table has attributes that you would like to slice by (create a dimension from), you would use this relationship type.

Functionally, to the users it behaves no differently than a regular relationship.

安穩 2024-12-21 08:14:55

创建维度和多维数据集后,您需要定义每个维度与每个度量值组的关联方式。度量值组是由单个事实表公开的一组度量值。

每个多维数据集可以包含多个事实表和多个维度。然而,并非每个维度都与每个事实表相关。

要定义关系,请右键单击 BIDS 中的多维数据集并选择打开;然后导航到“维度用法”选项卡。如果单击每个维度旁边的省略号按钮,您将看到一个屏幕,允许您更改特定度量值组的维度使用情况。您可以从以下选项中进行选择:

  • 常规默认选项;维度直接连接到事实表

  • 无关系 维度与当前度量值组不相关

  • 事实维度和事实源自单个表。如果是这种情况,您的维度仓库设计不佳,并且不太可能表现良好。考虑分离事实表和维度表。

  • 引用维度在连接到事实表之前先连接到中间表。引用关系类似于雪花维度,但略有不同。假设您有一个客户维度和一个销售事实;您想要按客户检查总销售额,但还想按客户检查行项目销售额。您可以将销售事实视为将客户连接到行项目的中间表,而不是在行项目事实表中复制客户键。

  • 多对多此选项涉及两个事实表和两个维度表。维度 A 连接到中间事实 A,中间事实 A 又连接到维度 B,事实 B 又连接到维度 B。与事实选项非常相似,如果您需要使用多对多选项,您的设计可能需要一些改进。如果您在第三范式的关系数据库之上构建多维数据集,则有时需要这种类型的关系。强烈建议对所有多维数据集使用具有星型模式的维度模型。例如,您可以有两个事实表:车辆和选项;每辆车都有多种选择。您可能会按客户检查车辆销售情况,并按每个选项中包含的项目检查选项。因此,您将拥有客户维度和项目维度。您可能还想按包含的项目检查车辆销售情况。如果是这样,车辆事实将被加入到选项事实和客户维度中;选项事实也将连接到项目的维度。

  • 数据挖掘目标维度基于从源维度构建的挖掘模型。源维度和目标维度都必须包含在多维数据集中。

After you create your dimensions and cubes you need to define how each dimension is related to each measure group. A measure group is a set of measures exposed by a single fact table.

Each cube can contain multiple fact tables and multiple dimensions. However, not every dimension will be related to every fact table.

To define relationships right click the cube in BIDS and choose open; then navigate to the Dimension Usage tab. If you click the ellipsis button next to each dimension you will see a screen that allows you to change dimension usage for a particular measure group. You can choose from the following options:

  • Regular default option; the dimension is joined directly to the fact table

  • No relationship the dimension is not related to the current measure group

  • Fact the dimension and fact are derived from a single table. If this is the case your dimensional warehouse has poor design and isn't likely to perform well. Consider separating fact and dimension tables.

  • Referenced the dimension is joined to an intermediate table prior to being joined to the fact table. Referenced relationship resembles a snowflake dimension, but is slightly different. Suppose you have a customer dimension and a sales fact; you'd like to examine total sales by customer, but you also want to examine line item sales by customer. Instead of duplicating the customer key in the line item fact table you can treat the sales fact as an intermediate table to join customer to line item.

  • Many-to-many this option involves two fact tables and two dimension tables. Dimension A is joined to an intermediate fact A, which in turn joins to dimension B to which the fact B is joined. Much like with fact option if you need to use many-to-many option your design could probably use some improvement. This type of relationship is sometimes necessary if you are building cubes on top of a relational database that is in 3rd normal form. It is strongly advisable to use a dimensional model with star schema for all cubes. For example you could have two fact tables: vehicles and options; each vehicle can come with a number of options. You're likely to examine vehicle sales by customer, and options by the items that are included in each option. Therefore you would have a customer dimension and item dimension. You could also want to examine vehicles sales by included item. If so the vehicle fact would be joined to the options fact and customer dimension; the options fact would also join to items' dimension.

  • Data mining target dimension is based on a mining model which is built from a source dimension. Both source dimension and target dimension must be included in the cube.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文