我一直在尝试构建一个专门用于 Pentaho 5.0 的 Mondrian 模式（我不确定版本在这里是否重要。）我似乎反复遇到的一个问题是如何控制数据与数据的呈现本身。让我举一个例子来说明。
想象一个立方体，例如：（D 表示维度，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 并且完全相互依赖。每一个都是唯一的钥匙。两者之间没有实际的等级关系。我将它们简单地视为同一数据的 2 种不同表示。这里最大的障碍是，如果它们不在同一个层次结构中，那么 Pentaho 可以自由地将它们放置在相反的轴上。这使得看起来很荒谬的报告如下：
United States Dollar | Canadian Dollar | Euro | ...
USD | 12345 | - | - |
CAD | - | 12345 | - |
EUR | - | - | 1234 |
...
当您希望简洁时，代码非常好。但是，也许您正在处理涉及几种不常见货币的特定情况，并且您不想让报告读者不得不查找更晦涩代码的含义。我探索了<Property>元素的使用，但 Pentaho 再次缺乏灵活性，因为您必须显示成员列才能显示属性值。如果名称是代码成员的属性，则无法在报表中仅显示货币名称而不包括代码，这是多余的。
最终，我希望有一些机制来控制数据的呈现，或者模式设计中的一些技术，为在 Pentaho 中进行分析的最终用户带来合理、连贯的体验。