Mondrian Schema详解SchemaSchema 定义了一个多维数据库。
包含了一个逻辑模型，而这个逻辑模型的目的是为了书写 MDX 语言的查询语句。
这个逻辑模型实际上提供了这几个概念：Cubes （立方体）、维度（ Dimensions ）、层次（ Hierarchies ）、级别（ Levels ）、和成员（ Members ）。
而一个 schema 文件就是编辑这个 schema 的一个 xml 文件。
在这个文件中形成逻辑模型和数据库物理模型的对应。
属性：Cube一个 Cube 是一系列维度 (Dimension) 和度量 (Measure) 的集合区域。
在Cube 中， Dimension 和 Measure 的共同地方就是共用一个事实表。
Cube 中的有以下几个属性：Cube 里面有一个全局的标签定义了所用的事实表的表名元素：如果事实表不在默认的数据库schema 中，你需要通过使用”schema”属性明确指出:Dimension他是一个层次（ Hierarchies ）的集合 , 维度一般有其相对应的维度表 . 他的组成是由层次（ Hierarchies ）而层次（ Hierarchies ）又是有级别（ Level ）组成 . 其属性如下：Hierarchy你一定要指定其中的各种关系 , 如果没有指定 , 就默认 Hierarchy 里面装的是来自立方体中的真实表 . 属性如下：Level级别 , 他是组成 Hierarchy 的部分。
属性很多，并且是 schema 编写的关键，使用它可以构成一个结构树， Level 的先后顺序决定了 Level 在这棵树上的的位置，最顶层的 Level 位于树的第一级，依次类推。
Level 的属性如下：MeasureMeasure 就是我们要计算的数值，操作的核心。
它的属性如下：Join对于一个 Hierarchy 来说，有两种方式为其指定：一种是直接通过一个 Table 标签指定；一种是通过 Join 将若干张表连接起来指定。
一旦采用 Join 的话，那么就要在 Hierarchy 里的 primaryKeyTable 属性指定主表。
进行Mondrian的MDX语法检查2009-08-06 22:27主要是通过mondrian.olap包中的一些核心类来进行MDX语法的检查。
首先，通过mondrian.olap.DriverManager来获取一个链接对象mondrian.olap.Connection.Connection connection =DriverManager.getConnection("Provider=mondrian;Jdbc=jdbc:oracle:thin:@xxx.xxx.xxx.xxx:1521:dbname;JdbcUser=dbuser;JdbcPassword=dbpasswd;Catalog=file:///c:/Tomcat4.1/webapps/mywebapp/WEB-INF/mondriantest.x ml;JdbcDrivers=oracle.jdbc.driver.OracleDriver;",null,false);再对查询的MDX语句进行处理，使其转化为一个可查询的Query对象。
String queryStr="select {[Measures].[Salary]} ON COLUMNS,{[Employee].[employeeId].Members} ON ROWSfrom CubeTest ";Query query =connection.parseQuery(queryStr);到此为止，如果query不为空，并且parseQuery没有出现异常的话，就算是语法检查通过了。
当然，如果要进行查询结果输出的话，就显示很简单了，先查询得到 Result，再对Result进行处理就可以了。
Result result = connection.execute(query);mondrian中的Element描述2009-08-06 22:54根元素<Schema> Collection of Cubes, Virtual cubes, Shared dimensions, and Roles.逻辑元素<Cube> A collection of dimensions and measures, all centered on a fact table.<VirtualCube> A cube defined by combining the dimensions and measures of one or more cubes.<Dimension><DimensionUsage> Usage of a shared dimension by a cube.<Hierarchy><Level><Property><Measure>物理元素<Table> Fact- or dimension table.<View> Defines a 'table' using a SQL query, which can have different variants for different underlying databases.<Join> Defines a 'table' by joining a set of queries.存取控制<Role> An access-control profile.<SchemaGrant> A set of rights to a schema.<CubeGrant> A set of rights to a cube.<HierarchyGrant> A set of rights to a hierarchy and levels within that hierarchy.<MemberGrant> A set of rights to a member and its children.其他<Parameter><Table><Table>根元素<Schema>多维数据集，虚拟多维数据集，共享维度和角色集.逻辑元素<Cube>集合的尺寸和措施，都集中在一个事实表。
<VirtualCube>多维数据集定义的通过组合中的一个或多个立方体的尺寸和措施。
<Dimension><DimensionUsage>共享维度的多维数据集的使用。
<Hierarchy><Level><Property><Measure>物理元素<Table>事实维度表。
<View>定义一个“表”使用SQL查询，它可以有不同的变种不同的底层数据库。
<Join>定义了一个“表”，通过加入一组查询.存取控制<Role>一个访问控制配置文件.<SchemaGrant>一组权利的架构.<CubeGrant>一组权利的多维数据集.<HierarchyGrant>一组权利，在该层次结构的层次和水平。
<MemberGrant>一组的成员，其子女的权利.其他<Parameter><Table><Table>mondrian中的父子层次关系2009-08-06 23:01父子层次一个使用方便的层次有一个严格的层的集合, 成员与层紧密的联系.比如,在Product 层次中, 任何产品名称层的成员在商标层上都有一个父亲，商标层上的成员在产品子目录层也都有一个父亲. 这种结构对于现实世界中的数据有时候太严格了.一个父子层次只有一层 (不计算 'all' 层), 但是任何成员可以在同一层上有父亲成员. 一个典型的例子是Employees 层次:<Dimension name="Employees" foreignKey="employee_id"><Hierarchy hasAll="true" allMemberName="All Employees"primaryKey="employee_id"><Table name="employee"/><Level name="Employee Id" uniqueMembers="true" type="Numeric"column="employee_id" nameColumn="full_name"parentColumn="supervisor_id" nullParentValue="0"><Property name="Marital Status" column="marital_status"/><Property name="Position Title" column="position_title"/><Property name="Gender" column="gender"/><Property name="Salary" column="salary"/><Property name="Education Level" column="education_level"/><Property name="Management Role" column="management_role"/></Level></Hierarchy></Dimension>这里parentColumn 和nullParentValue是重要的属性:属性parentColumn 是一个成员连接到它父亲成员的列名。
