此问题与BusinessObjects 4.0（1）中的数据建模有关。
开始：要求是创建BO Universe。用户希望在5个事实表之上进行查询，因为他正在寻找的业务答案位于相同的上下文中（在5个事实表的上下文中）。另一个重要特征是这5个事实表共享许多共同的维度。
我采取的方法：我决定创建一个包含所有5个事实表的Universe。然后我遇到了以下困境 - 因为事实表“共享”相同的维度，我应该使用上下文来避免循环，还是应该使用别名？我决定使用别名。结果我提出了以下data model。有了这个数据模型，我确信没有循环（因为它可能是上下文的情况）。
我遇到的下一个难题是在业务层创建过程中。由于我有5个事实表，我的第一个想法是为每个事实表创建5个不同的文件夹，然后将相应的维度放在同一个文件夹中（如图所示）。
此外，当我尝试查询Universe时，当我只使用一个事实表及其相应的维度时，所有功能都正常运行。但是，当我尝试组合属于不同事实表的对象时，我收到一条错误消息，上面写着“由于笛卡尔产品导致查询生成操作已停止”。
问题：
答案 0 :(得分：1)
没有确切的公式何时选择别名或上下文。两者都有他们的利弊。
在您的情况下，使用别名会导致BL中出现大量重复对象（例如时间维度）。这会使最终用户的Universe复杂化，但也会进一步维护，因为对这些共享维度的任何更改都可能导致可能需要多次重复相同的修改。
我只会在
时使用别名我不会将时间维度别名，因为这是一个共同的维度，无论它链接到哪个表，其含义都是相同的。
如果您要使用上下文，您实际上可以从不同的事实表中进行选择（假设您已启用允许从查询中的多个上下文中进行选择的选项）并包含公共维。此外，这样您就不会强制最终用户在报告中将不同的查询合并在一起。
有关详细信息，请查看Information Design Tool User Guide。第10.13和10.14节分别处理别名和上下文。
答案 1 :(得分：0)
创建一个包含5个事实表以及维表（具有所需维信息）的Universe。使用一个事实表和所需的维度信息创建上下文（对所有5个上下文执行相同的过程）。所以基本上您将有5个上下文。
5个事实表文件夹 1个文件夹，用于所有5个查询中的通用尺寸。
现在要将来自所有5个事实表的数据保存在一个报告中，请用户进行合并。
这是唯一的解决方案。如果用户不知道如何合并尺寸，请教一次。