• If a dimension has a small number of members, Mondrian reads it into a cache on first use. See the mondrian.rolap.LargeDimensionThreshold property.
• If a dimension (or, more precisely, the level of the dimension being accessed) is in the fact table, Mondrian does not perform a join.
• If two dimensions access the same table via the same join path, Mondrian only joins them once. For example, [Gender] and [Age] might both be columns in the customerstable, joined via sales_1997.cust_id = customers.cust_id.

假设你想要创建一个度量，但事实表中并没有这个列，一种方法是使用WITH MEMBER子句，如下：

WITH MEMBER [Measures].[Profit] AS '[Measures].[Store Sales]-[Measures].[Store Cost]',
   FORMAT_STRING = '$#,###'
SELECT {[Measures].[Store Sales], [Measures].[Profit]} ON COLUMNS,
  {[Product].Children} ON ROWS
FROM [Sales]
WHERE [Time].[1997]

但更好的办法是在模式中定义这个成员，下面在是cube中的定义

<CalculatedMember name="Profit" dimension="Measures">
  <Formula>[Measures].[Store Sales] - [Measures].[Store Cost]</Formula>
  <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/>
</CalculatedMember>

如果你喜欢，也可以在属性中声明，如下：

<CalculatedMember name="Profit" dimension="Measures"
    formula="[Measures].[Store Sales]-[Measures].[Store Cost]">
  <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/>
</CalculatedMember>

<CalculatedMemberProperty > (not <Property>) 元素和MDX语句中的FORMAT_STRING = '$#,###'片段相符，你也可以在这里定义其他特征(properties)，但FORMAT_STRING是到目前为止最常用的。

FORMAT_STRING特征值还可以用一个表达式来判断，在格式化一个单元时，第一个表达式(value<0)将用于判断选择哪个format string来进行格式化，然后才将 相应的format string 用于指定的单元值，下面是一个添加了额外表达式的例子：

<CalculatedMemberProperty name="FORMAT_STRING"
    expression="Iif(Value < 0, '|($#,##0.00)|style=red', '|$#,##0.00|style=green')"/>

Sometimes Mondrian's schema language isn't flexible enough, or the MDX language isn't powerful enough, to solve the problem at hand. What you want to do is add a little of your own Java code into the Mondrian application, and a plug-in is a way to do this.

Each of Mondrian's extensions is technically a Service Provider Interface (SPI); in short, a Java interface which you write code to implement, and which Mondrian will call at runtime. You also need to register an extension (usually somewhere in your schema.xml file) and to ensure that it appears on the classpath.

Plug-ins include user-defined functions; cell, member and property formatters; dynamic schema processors and data source change listeners. There is incomplete support for member readers and cell readers, and in future we may support pluggable SQL dialects.

Other extensions include Dynamic datasource xmla servlet

A user-defined function must have a public constructor and implement the mondrian.spi.UserDefinedFunction interface. For example,

package com.acme;

import mondrian.olap.*;
import mondrian.olap.type.*;
import mondrian.spi.UserDefinedFunction;

/**
 * A simple user-defined function which adds one to its argument.
 */
public class PlusOneUdf implements UserDefinedFunction {
    // public constructor
     public Object execute(Evaluator evaluator, Exp[] arguments) {
        final Object argValue = arguments[0].evaluateScalar(evaluator);
        if (argValue instanceof Number) {
            return new Double(((Number) argValue).doubleValue() + 1);
        } else {
            // Argument might be a RuntimeException indicating that
            // the cache does not yet have the required cell value. The
            // function will be called again when the cache is loaded.
            return null;
        }
    }

    public String[] getReservedWords() {
        return null;
    }
}

Declare it in your schema:

<Schema>
  ...
  <UserDefinedFunction name="PlusOne" class="com.acme.PlusOneUdf" />
</Schema>

And use it in any MDX statement:

WITH MEMBER [Measures].[Unit Sales Plus One] 
    AS 'PlusOne([Measures].[Unit Sales])'
SELECT
    {[Measures].[Unit Sales]} ON COLUMNS,
    {[Gender].MEMBERS} ON ROWS
FROM [Sales]

If a user-defined function has a public constructor with one string argument, Mondrian will pass in the function's name. Why? This allows you to define two or more user-defined functions using the same class:

package com.acme;

import mondrian.olap.*;
import mondrian.olap.type.*;
import mondrian.spi.UserDefinedFunction;

/**
 * A user-defined function which either adds one to or 
 * subtracts one from its argument.
 */
public class PlusOrMinusOneUdf implements UserDefinedFunction {
    private final name;
    private final isPlus;

    // public constructor with one argument
    public PlusOneUdf(String name) {
        this.name = name;
        if (name.equals("PlusOne")) {
            isPlus = true;
        } else if (name.equals("MinusOne")) {
            isPlus = false;
        } else {
            throw new IllegalArgumentException("Unexpected name " + name);
        }
    }

   public Object execute(Evaluator evaluator, Exp[] arguments) {
        final Object argValue = arguments[0].evaluateScalar(evaluator);
        if (argValue instanceof Number) {
            if (isPlus) {
                return new Double(((Number) argValue).doubleValue() + 1);
            } else {
                return new Double(((Number) argValue).doubleValue() - 1);
            }
        } else {
            // Argument might be a RuntimeException indicating that
            // the cache does not yet have the required cell value. The
            // function will be called again when the cache is loaded.
            return null;
        }
    }

    public String[] getReservedWords() {
        return null;
    }
}

and register two the functions in your schema:

<Schema>
  ...
  <UserDefinedFunction name="PlusOne" class="com.acme.PlusOrMinusOneUdf">
  <UserDefinedFunction name="MinusOne" class="com.acme.PlusOrMinusOneUdf">
</Schema>

If you're tired of writing duplicated User-defined Function declarations in schema files, you can pack your User-defined Function implemention classes into a jar file with a embedded resource file META-INF/services/mondrian.spi.UserDefinedFunction. This resource file contains class names of implementations of interface mondrian.spi.UserDefinedFunction, one name per line. For more details, you may look into src/main/META-INF/services/mondrian.spi.UserDefinedFunction in source ball and Service Provider. User-defined Functions declared by this means are available to all mondrian schema in one JVM.

Caution: you can't define more than one User-defined Function implementations in one class when you declare User-defined Functions in this way.

Member reader：成员读取器用于访问成员

Aggregate tables：汇总表

下面是一个简单的汇总表.

<Cube name="Sales">
  <Table name="sales_fact_1997">
    <AggName name="agg_c_special_sales_fact_1997">  <!--聚合表名字-->

<AggForeignKeyfactColumn="product_id" aggColumn="product_id"/>  
      <AggFactCount column="FACT_COUNT"/>
      <AggMeasure name="[Measures].[Store Cost]" column="STORE_COST_SUM"/>
      <AggMeasure name="[Measures].[Store Sales]" column="STORE_SALES_SUM"/>
      <AggLevel name="[Product].[Product Family]" column="PRODUCT_FAMILY"/>
      <AggLevel name="[Time].[Quarter]" column="TIME_QUARTER"/>
      <AggLevel name="[Time].[Year]" column="TIME_YEAR"/>
      <AggLevel name="[Time].[Quarter]" column="TIME_QUARTER"/>
      <AggLevel name="[Time].[Month]" column="TIME_MONTH"/>
    </AggName>
  </Table>

  <!-- Rest of the cube definition -->
</Cube>

<AggForeignKey> 元素, 这里没有显示, 允许你直接引用一个维表，而不必包含汇总表中的列. It is described in the aggregate tables guide.

In practice, a cube which is based upon a very large fact table may have several aggregate tables. It is inconvenient to declare each aggregate table explicitly in the schema XML file, and luckily there is a better way. In the following example, Mondrian locates aggregate tables by pattern-matching.

<Cube name="Sales">
  <Table name="sales_fact_1997">
    <AggPattern pattern="agg_.*_sales_fact_1997">  <!--正则匹配(不同主题匹配不同否则会报错)--> 
      <AggFactCount column="FACT_COUNT"/>
      <AggMeasure name="[Measures].[Store Cost]" column="STORE_COST_SUM"/>
      <AggMeasure name="[Measures].[Store Sales]" column="STORE_SALES_SUM"/>
      <AggLevel name="[Product].[Product Family]" column="PRODUCT_FAMILY"/>
      <AggLevel name="[Time].[Quarter]" column="TIME_QUARTER"/>
      <AggLevel name="[Time].[Year]" column="TIME_YEAR"/>
      <AggLevel name="[Time].[Quarter]" column="TIME_QUARTER"/>
      <AggLevel name="[Time].[Month]" column="TIME_MONTH"/>
      <AggExclude name="agg_c_14_sales_fact_1997"/>  <!--排除该表-->
      <AggExclude name="agg_lc_100_sales_fact_1997"/>
    </AggPattern>
  </Table>
</Cube>

It tells Mondrian to treat all tables which match the pattern "agg_.*_sales_fact_1997" as aggregate tables, except "agg_c_14_sales_fact_1997" and "agg_lc_100_sales_fact_1997". Mondrian uses rules to deduce the roles of the columns in those tables, so it's important to adhere to strict naming conventions. The naming conventions are described in the aggregate tables guide.

The performance guide has advice on choosing aggregate tables.

agg_.+_sales_fact_1997

This will match the following table names:

• agg_l_05_sales_fact_1997
• agg_c_14_sales_fact_1997
• agg_lc_100_sales_fact_1997
• agg_c_special_sales_fact_1997
• AGG_45_SALES_FACT_1997
• AGG_drop_time_id_sales_fact_1997

<Cube name="Sales">
  <Table name="sales">
    <AggName name="agg_2_sales">
      <AggFactCount column="row count"/>
      <AggForeignKey factColumn="prodid" aggColumn="prodid"/>
      <AggMeasure name="[Measures].[Unit Sales]" column="sum units"/>
      <AggMeasure name="[Measures].[Min Units]" column="min units"/>
      <AggMeasure name="[Measures].[Max Units]" column="max units"/>
      <AggMeasure name="[Measures].[Dollar Sales]" column="sum dollars"/>
      <AggLevel name="[Time].[Year]" column="year"/>
      <AggLevel name="[Time].[Quarter]" column="quarter"/>
      <AggLevel name="[Time].[Month]" column="month"/>
      <AggLevel name="[Payment Method].[Payment Method]" column="payment"/>
      <AggLevel name="[Customer].[State]" column="state"/>
    </AggName>
  </Table>
  <Dimension name="Product">
    <Hierarchy hasAll="true" primaryKey="prodid" primaryKeyTable="Product">
      <Join leftKey="mfrid" rightKey="mfrid">
        <Table name="Product"/>
        <Table name="Mfr"/>
      </Join>
      <Level name="Manufacturer" table="Mfr" column="mfrid"/>
      <Level name="Brand" table="Product" column="brand"/>
      <Level name="Name" table="Product" column="prodid"/>
    </Hierarchy>
  </Dimension>
  <Dimension name="Day" foreignKey="day">
    <Hierarchy hasAll="true" primaryKey="day">
      <Table name="Time" />
      <Level name="Year" column="year" type="Numeric" uniqueMembers="true" />
      <Level name="Quarter" column="quarter" uniqueMembers="false" />
      <Level name="Month" column="month" type="Numeric" uniqueMembers="false" />
    </Hierarchy>
  </Dimension>
  <Dimension name="Customer" foreignKey="custid">
    <Hierarchy hasAll="true" primaryKey="custid">
      <Table name="Customer" />
      <Level name="City" column="city" uniqueMembers="ture" />
      <Level name="State" column="state" uniqueMembers="true" />
    </Hierarchy>
  </Dimension>
  <Dimension name="Payment method">
    <Hierarchy hasAll="true">
      <Level name="Payment method" column="payment" uniqueMembers="ture" />
    </Hierarchy>
  </Dimension>
  <AggMeasure name="Unit Sales" aggregator="sum" />
  <AggMeasure name="Min Units" aggregator="min" />
  <AggMeasure name="Max Units" aggregator="max" />
  <AggMeasure name="Dollar Sales" aggregator="sum" />
</Cube>