BI中如何配置模式文件（Schema）
在这里系统的看看构成模式文件的元素：
首先说明一点：这个sample中每一部分在形式上有很多重复的地方，为了尽可能地讲的完全，所以在讲解的过程中，
每一部分提取形式上不重复的部分，然后加入该部分的一些可选项，同时可以查阅FoodMart.xml这个Schema文件。
从宏观上来看，配置一个Schema大致可以分成五部分,分别是：1、Table配置 2、Dimension配置 3、Measure配置 4、VirtualCube配置 5、访问权限配置。在本sample中已经标记出，下面分析每一部分中的元素构成。
<第一部分>
? <Table name="sales_fact_1997">
??? <AggExclude name="agg_c_14_sales_fact_1997" />
??? <AggName name="agg_c_special_sales_fact_1997">
??????? <AggFactCount column="FACT_COUNT"/>
??????? <AggIgnoreColumn column="foo"/>
??????? <AggForeignKey factColumn="product_id" aggColumn="PRODUCT_ID" />
??????? <AggMeasure name="[Measures].[Unit Sales]" column="UNIT_SALES_SUM" />
??????? <AggLevel name="[Time].[Year]" column="TIME_YEAR" />
??? </AggName>
??? <AggPattern pattern="agg_sales_fact_1997_.*">
??????? ....
??? ??<AggExclude name="agg_sales_fact_1997_olddata" />
??? ??<AggExclude pattern="agg_sales_fact_1997_test.*" />
??</AggPattern>
?</Table>
</第一部分>
1、首先给出表名，在一般情况下，一个Cube是建立在一张事实表之上的，所以Table name=某事实表，但也可以在一张基础表上建立Cube。
2、在本sample中加入了一个聚合表（aggregate table），在一个Cube中可以加，也可以不加，需要根据实际情况来决定。聚合表的作用简单的说表现在考虑报表设计时，通过聚合预先计算好数据汇总，从而改进查询响应的时间。聚合表的内容非常丰富，在这里只讲解最基本的概念，进一步了解请访问官网http://mondrian.pentaho.com/documentation/aggregate_tables.php，接下来简单的理解构成聚合表的元素。
3、AggExclude name，这里给出的表名旨在告诉Mondrian该表不是相应事实表的聚合表。
4、AggName name，这里给出的表名告诉Mondrian该表是相应事实表的聚合表
5、AggFactCount column="FACT_COUNT"，这个字段在每一张聚合表中都存在，记录了相应的事实表中有多少列写入到聚合表中。
6、AggIgnoreColumn column，该列名的作用是告知Mondrian该列是已知的，应该被忽略。
7、<AggForeignKey factColumn="product_id" aggColumn="PRODUCT_ID"/>这里给出了一个映射关系，即事实表中的product_id列对应了聚合表中的PRODUCT_ID列。
8、AggMeasure name和AggLevel name这两个元素同样也给出了一个映射关系，即把在Cube的模式文件中定义的逻辑名映射到聚合表中的列名。
9、AggPattern pattern使用了正则表达式，把符合该pattern的聚合表包括进来。如在本sample中把前缀为agg_sales_fact_1997_的聚合表全部包括进来作为孩子元素。
10、AggPattern pattern中的AggExclude name元素，该元素很明确地指出在已包括进来的聚合表中，剔除某特定的聚合表。
11、AggPattern pattern中的AggExclude pattern元素，该元素的作用表现在把符合AggExclude pattern的正则表达式的聚合表剔除。
12、第一部分的完整框架是：
??<Table>
???? <AggExclude>
???? <AggName>
???????? <AggFactCount/>
???????? <AggIgnoreColumn/>
???????? <AggForeignKey/>
???????? <AggMeasure/>
???????? <AggLevel/>
???? </AggName>
???? <AggPattern>
???? ??<AggExclude name/>
???? ??<AggExclude pattern/>
???</AggPattern>
??</Table>
?
?
<第二部分>
? <DimensionUsage name="Store" source="Store" foreignKey="store_id"/>
? <Dimension name="Promotion Media" foreignKey="promotion_id">
??? <Hierarchy hasAll="true" allMemberName="All Media" primaryKey="promotion_id" defaultMember="All Media">
????? <Table name="promotion"/>
????? <Level name="Media Type" column="media_type" uniqueMembers="true"/>
??? </Hierarchy>
? </Dimension>
? <Dimension name="Customers" foreignKey="customer_id">
??? <Hierarchy hasAll="true" allMemberName="All Customers" primaryKey="customer_id">
????? <Table name="customer"/>
????? <Level name="City" column="city" uniqueMembers="false"/>
????? <Level name="Name" column="customer_id" type="Numeric" uniqueMembers="true">
??????? <NameExpression>
????????? <SQL dialect="oracle">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="access">fname + ' ' + lname</SQL>
????????? <SQL dialect="postgres">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="mysql">CONCAT(`customer`.`fname`, ' ', `customer`.`lname`)</SQL>
????????? <SQL dialect="mssql">fname + ' ' + lname</SQL>
????????? <SQL dialect="derby">"customer"."fullname"</SQL>
????????? <SQL dialect="db2">CONCAT(CONCAT("customer"."fname", ' '), "customer"."lname")</SQL>
????????? <SQL dialect="luciddb">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="generic">fullname</SQL>
??????? </NameExpression>
??????? <OrdinalExpression>
????????? <SQL dialect="oracle">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="access">fname + ' ' + lname</SQL>
????????? <SQL dialect="postgres">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="mysql">CONCAT(`customer`.`fname`, ' ', `customer`.`lname`)</SQL>
????????? <SQL dialect="mssql">fname + ' ' + lname</SQL>
????????? <SQL dialect="derby">"customer"."fullname"</SQL>
????????? <SQL dialect="db2">CONCAT(CONCAT("customer"."fname", ' '), "customer"."lname")</SQL>
????????? <SQL dialect="luciddb">"fname" || ' ' || "lname"</SQL>
????????? <SQL dialect="generic">fullname</SQL>
??????? </OrdinalExpression>
??????? <Property name="Gender" column="gender"/>
??????? <Property name="Marital Status" column="marital_status"/>
??????? <Property name="Education" column="education"/>
??????? <Property name="Yearly Income" column="yearly_income"/>
????? </Level>
??? </Hierarchy>
? </Dimension>
</第二部分>
1、DimensionUsage元素：如果在之前定义了共享维（shared dimensions),并且在该Cube中想要使用该共享维，
那么就如<DimensionUsage name="Store" source="Store" foreignKey="store_id"/>使用，通过store_id把
事实表sales_fact_1997和基础表Store相连接。
2、<Dimension name="Promotion Media" foreignKey="promotion_id">
??? <Hierarchy hasAll="true" allMemberName="All Media" primaryKey="promotion_id" defaultMember="All Media">
????? <Table name="promotion"/>
????? <Level name="Media Type" column="media_type" uniqueMembers="true"/>
??? </Hierarchy>
?? </Dimension>
? 定义了一个名为Promotion Media的维，通过promotion_id连接基础表promotion和事实表sales_fact_1997。
?<Level name="Media Type" column="media_type" uniqueMembers="true"/>定义了一个层次中的级别，选择了基础表promotion的media_type字段，不包括该表中的其他字段。
3、在本上面的例子中又定义了一个名为Customers的demension，通过字段customer_id连接基础表customer和事实表sales_fact_1997。接下来来解释下其他元素的作用：
?<Level name="XXXX" column="XXXX" type="XXXX" uniqueMembers="XXXX">
????<KeyExpression>
?????SQL表达式，用于该级别的key，代替了column
????</KeyExpression>
????<CaptionExpression>
?????SQL表达式，用于计算一个成员的标题，代替了Level.captionColumn
????</CaptionExpression>
????<ParentExpression>
?????SQL表达式，用于计算一个度量，代替了Level.parentColumn
????</ParentExpression>
??????? <NameExpression>
????????? SQL表达式，用于计算一个成员的名字，代替了Level.nameColumn
??????? </NameExpression>
??????? <OrdinalExpression>
????????? SQL表达式，用于对一个level的所有成员进行排序，代替了Level.ordinalColumn
??????? </OrdinalExpression>
??????? <Property name="XXXX" column="XXXX">
??????? ?<PropertyExpression>
??????? ??SQL表达式，用于计算一个属性的值，代替了Property.column
??????? ?</PropertyExpression>
??????? </Property>
? </Level>
4、第二部分的完整框架是：
??<DimensionUsage/>
?? <Dimension>
???? <Hierarchy>
?????? <Table name=/>
?????? <Level name=/>
???? </Hierarchy>
?? </Dimension>
?? <Dimension name>
???? <Hierarchy>
?????? <Table name=/>
?????? <Level name=/>
?????? <Level name=>
???????? <KeyExpression>
??????<SQL dialect></SQL>
?????</KeyExpression>
?????<CaptionExpression>
??????<SQL dialect></SQL>
?????</CaptionExpression>
?????<ParentExpression>
??????<SQL dialect></SQL>
?????</ParentExpression>
???????? <NameExpression>
?????????? <SQL dialect></SQL>
???????? </NameExpression>
???????? <OrdinalExpression>
?????????? <SQL dialect></SQL>
???????? </OrdinalExpression>
???????? <Property name="XXXX" column="XXXX">
???????? ?<PropertyExpression>
???????? ??<SQL dialect></SQL>
???????? ?</PropertyExpression>
???????? </Property>
?????? </Level>
???? </Hierarchy>
?? </Dimension>
?
?
<第三部分>
? <Measure name="Unit Sales" column="unit_sales" aggregator="sum" formatString="Standard"/>
? <Measure name="Promotion Sales" aggregator="sum" formatString="#,###.00">
??? <MeasureExpression>
????? <SQL dialect="oracle">(case when "sales_fact_1997"."promotion_id" = 0 then 0 else "sales_fact_1997"."store_sales" end)</SQL>
??? </MeasureExpression>
? </Measure>
? <CalculatedMember name="Profit" dimension="Measures">
??? <Formula>[Measures].[Store Sales] - [Measures].[Store Cost]</Formula>
??? <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/>
? </CalculatedMember>
</第三部分>
1、第一个Measure的名字是Unit Sales，对应事实表中的unit_sales列，聚合的方法是求和（还可以是：sum,count,min,max,avg,distinct-count），求和之后的结果格式为标准格式。
2、第二个Measure的名字是Promotion Sales，在该Measure下加入了一个MeasureExpression。期望是：从事实表sales_fact_1997中挑选出promotion_id=0的所有行，然后对该事实表的store_sales进行求和（如果某行的sales_fact_1997.store_sales=0，则不对该行进行计算）
3、CalculatedMember元素是一个计算成员，在本sample中取名Profit，属于Measures维。期望是：商店的销售额减去商店的成本得到利润值，得到的值的类型是字符串类型，值的格式是$#,##0.00
4、第三部分一个完整的框架是：
??<Measure>
???<MeasureExpression>
????<SQL/>
???</MeasureExpression>
??</Measure>
??<CalculatedMember>
???<Formula/>
???<CalculatedMemberProperty/>
??</CalculatedMember>
??<NamedSet>
???该集合的值是由公式推导出的，是Cube的组成部分
??</NamedSet>
??
?
<第四部分>
?<VirtualCube name="Warehouse and Sales" defaultMeasure="Store Sales">
?? <VirtualCubeDimension cubeName="Sales" name="Customers"/>
?? <VirtualCubeDimension name="Product"/>
?? <VirtualCubeMeasure cubeName="Sales" name="[Measures].[Sales Count]"/>
?? <CalculatedMember name="Profit Per Unit Shipped" dimension="Measures">
???? <Formula>[Measures].[Profit] / [Measures].[Units Shipped]</Formula>
?? </CalculatedMember>
?</VirtualCube>
</第四部分>
1、VirtualCube，A cube defined by combining the dimensions and measures of one or more cubes. A measure originating from another cube can be a <CalculatedMember>.即若干个Cube中的dimension和measure相结合形成一个Cube，该Cube就叫做VirtualCube。来自另一个Cube的measure可以是该VirtualCube的计算成员。
2、在本sample中定义了一个叫Warehouse and Sales的多维虚拟分析主题，VirtualCubeDimension定义了一个来自Sales的Cube，并且选择了该Cube中的Customers维。注意在VirtualCubeDimension的定义中还有另一种方法，如<VirtualCubeDimension name="Product"/>，这是针对共享维的使用方法。
3、VirtualCubeMeasure定义了一个来自Sales的Cube，并且选择了该Cube中的Sales Count度量。
4、CalculatedMember定义了一个计算成员，使用方法和一般的Cube一样。
5、第四部分一个完整的框架是：
??<VirtualCube>
???<CubeUsages>
????<CubeUsage>
????</CubeUsage>
???</CubeUsages>
???
??? <VirtualCubeDimension>
??? </VirtualCubeDimension>
???
???<VirtualCubeMeasure>
???</VirtualCubeMeasure>
???
???<CalculatedMember>
???</CalculatedMember>
??</VirtualCube>
??或者如本sample中的写法，即把在VirtualCube中要使用到的Cube写在<VirtualCubeDimension>，<VirtualCubeMeasure>和<CalculatedMember>中，
??从而不需要在<CubeUsages>中定义。
?
??
<第五部分>
<Role name="California manager">
? <SchemaGrant access="none">
??? <CubeGrant cube="Sales" access="all">
????? <HierarchyGrant hierarchy="[Store]" access="custom" topLevel="[Store].[Store Country]">
??????? <MemberGrant member="[Store].[USA].[CA]" access="all"/>
??????? <MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/>
????? </HierarchyGrant>
????? <HierarchyGrant hierarchy="[Gender]" access="none"/>
??? </CubeGrant>
? </SchemaGrant>
</Role>
</第五部分>
1、该部分属于访问控制配置文件
2、Role定义了一个访问者
3、SchemaGrant是一个访问Schema的权利的集合
4、CubeGrant是一个访问Cube的权利的集合
5、HierarchyGrant是一个访问该层次以及属于该层次的级别的权利的集合
6、MemberGrant是一个访问成员以及该成员的孩子的权利的集合
在理解上述元素的情况下，我们来了解在本sample中该部分的作用：首先定义了一个访问用户，是California manager（加州经理），他不能访问整个Schema中的Cube，但他可以访问Sales这个Cube。其次，自定义了对该Sales Cube中的Store这个层次的访问控制，他可以访问位于美国加州的store（除了洛杉矶）。最后定义了他对该Sales Cube中的Gender层次无访问权限。
7、第五部分的完整框架是：
??<Role>
??? <SchemaGrant>
????? <CubeGrant>
??????? <HierarchyGrant>
????????? <MemberGrant/>
??????? </HierarchyGrant>
??????? <HierarchyGrant>
????? </CubeGrant>
??? </SchemaGrant>
??</Role>
