我一直在尝试构建一个专门用于Pentaho 5.0的Mondrian架构（我不确定这个版本在这里很重要。）我似乎反复提出的一个问题是如何控制数据的表示vs数据本身。让我举一个例子来说明。
想象一个立方体，例如：（D代表Dimension，H代表层次结构，L代表级别）
D: time
H: default
L: year
L: month
L: day
D: currency
H: default
L: name
L: code
如果我们考虑time.year的成员，我相信我们都会同意他们会..., 2008, 2009, 2010, 2011, 2012, 2013, ...。那么让我们继续time.month。事情变得有趣。我们将time.month表示为数字或单词吗？为什么不同时拥有？
Mondrian提供了一种指定成员名称的方法以及成员的“标题”，它为成员提供了与成员姓名不同的值。大！但是如果我提供一个标题，那么在Pentaho中，你只能看到标题。从来没有原始会员名称。如何让我的用户选择哪个更合适？
月份级别（以及日期级别以及具有多个级别的任何层次结构）会导致另一个混淆源。如果月份表示为12个值之一（（数字或单词在此处没有区别），则实际成员值为time.[2012].[1], time.[2012].[2], ..., time.[2012][12], time.[2013].[1], ...。因此，对于6月（第6个月），有许多成员，例如..., time.[2009].[6], time.[2010].[6], time.[2011].[6], ...。因此，如果显示成员列表并且它仅包含成员名称的月份部分，那么我们会看到1,2,3,4,5,6,7,8,9,10,11,12,1,2,3,4,5,6,7,8,9,10,11,12,1,2,3,...。你不能区分相等的月份。 “只要包括年份专栏，”你说。是的，这是有道理的，但还有其他地方，Pentaho没有提供这样做的选项，例如在过滤对话框中。我有想法将年份包含在成员的标题中，而不仅仅是6或June，您会看到2012 June。不幸的是，这也不太理想。如果层次结构的每个级别都存在，（并且假设我们也在这一天遵循此模式），那么每行都看起来像2012 | 2012 June | 2012 June 13 | your_measure。这当然是愚蠢的。但是，当钻探Pentaho的报告时，这很容易出现。
我们的第二个维度也有类似的问题。想象一下世界货币类型的数据集。有3个字母的ISO标准货币代码和官方货币名称。这两个值是1：1并且完全相互依赖。每一个都是一个独特的钥匙。两者之间没有实际的等级关系。我将它们简单地看作是同一条数据的两种不同表示。这里最大的障碍是，如果它们不在同一层次结构中，那么Pentaho可以自由地将它们放在相反的轴上。这使得看起来很荒谬的报道如下：
United States Dollar | Canadian Dollar | Euro | ...
USD | 12345 | - | - |
CAD | - | 12345 | - |
EUR | - | - | 1234 |
...
当你想要简洁时，代码非常好。但是，您可能正在处理涉及多种不常见货币的特定情况，并且您不希望报表读者必须查找更加模糊的代码的含义。我探讨了<Property>元素的使用，但Pentaho再次缺乏灵活性，因为你必须显示成员列以显示属性值。如果名称是代码成员的属性，则无法在报告中仅显示货币名称，而不包括冗余的代码。
最终，我希望有一些控制数据表达的机制，或模式设计中的一些技术，为最终用户在Pentaho进行分析提供合理，连贯的体验。
答案 0 :(得分：2)
这很常见。
关于属性 - 如果你不能在分析仪中重新排序它们很烦人，它们似乎是一类二等公民。由于它们仍未在Saiku中得到支持或显示，因此通常意味着它们无论如何都无法使用。但是，在您的示例中，这确实是对属性的正确使用 - 实际上是一个很好的描述！
所以有一个解决方案，但它不是超级干净。您可以根据用户首选项定义不同的层次结构，然后使用基于角色的安全性来隐藏最终用户中的一个或另一个层次结构。
我对此完成的主题变体是对相同的多维数据集进行管理级别，高级级别和初级级别访问，您可以根据权限看到不同的级别和层次结构。
我没有时间进入Mondrian4，这可能会改善这里的一切，因为现在一切都只是一个属性 - 但我不是百分百肯定。
最后，我肯定会提供支持（听起来像你有一份支持合同）并看看可以做出哪些改进。在这里发布jira我肯定会赞成它！