developer_notes.html

基于mondrian 开源框架进行OLAP多维分析

values for the
<code>
space
</code>
and
<code>
dot
</code>
attributes and with
<code>
CaseMatcher
</code>
mapping to lower case
) this would become "unit_sales_case".
</p>
<p>
The 
<code>
IgnoreMap
</code>
element has NO template parameter names. Each
<code>
Regex
</code>
value is simply a regular expression. As an example (Mondrian by
default does not include an 
<code>
IgnoreMap
</code>
by default), a regular expression that matches all aggregate table columns
then end with '_DO_NOT_USE' would be:
</p>
<blockquote>
    .*_DO_NOT_USE<br>
</blockquote>
<p>
One might want to use an
<code>
IgnoreMap
</code>
element to filter out aggregate columns if, for example, the aggregate
table is a materialized view, since with each "normal" column
of such a materialized view there is an associated support column
used by the database which has no significance to Mondrian.
In the process of recognizing aggregate tables, Mondrian logs
a warning message for each column whose use can not be determined.
Materialized views have so many of these support columns
that if, in fact, there was a column whose use was desired
but was not recognized (for instance, the column name is 
misspelt) all of the materialized view column warning message
mask the one warning message that one really needs to see.
</p>
<p>
The 
<code>
IgnoreMap
</code>
regular expressions are applied before any of the other column
matching actions. If one sets the 
<code>
IgnoreMap
</code>
regular expression to, for example,
<blockquote>
    .*<br>
</blockquote>
</p>
<p>
then all columns are marked as "ignore" and there are no other
columns left to match anything else. One must be very careful
when choosing 
<code>
IgnoreMap
</code>
regular expressions not just for your current columns but for
columns that might be created in the future. Its best to document
this usage in your organization.
</p>
<p>
The following is what the element might look like in a
DefaultRules.xml file:
<blockquote>
<pre>
    &lt;IgnoreMap id="ixx" &gt;
      &lt;Regex id="physical" charcase="ignore"&gt;
          .*_DO_NOT_USE
      &lt;/Regex&gt;
    &lt;/IgnoreMap&gt;
</pre>
</blockquote>
</p>
<p>
The 
<code>
LevelMap
</code>
element has the four template parameter names (hardcoded):
</p>
<blockquote>
    hierarchy_name<br>
    level_name<br>
    level_column_name<br>
    usage_prefix<br>
</blockquote>
<p>
These are names that can be used in creating template regular 
expressions.
The builtin Mondrian default rules for level matching defines
three
<code>
Regex
</code>
child elements for the 
<code>
LevelMap
</code>
element.
These define the template regular expressions:
</p>
<blockquote>
    ${hierarchy_name}_${level_name}<br>
    ${hierarchy_name}_${level_column_name}<br>
    ${usage_prefix}${level_column_name}<br>
    ${level_column_name}<br>
</blockquote>
<p>
Mondrian while attempting to match a candidate aggregate table
against a particular fact table, iterates through the fact table's cube's
hierarchy name, level name and level colum names looking for
matches.
</p>
<p>
The
<code>
MeasureMap
</code>
element has the three template parameter names (hardcoded):
</p>
<blockquote>
    measure_name<br>
    measure_column_name<br>
    aggregate_name<br>
</blockquote>
<p>
which can appear in template regular expressions.
The builtin Mondrian default rules for measure matching defines
three
<code>
Regex
</code>
child elements for the 
<code>
MeasureMap
</code>
element.
These are
</p>
<blockquote>
    ${measure_name}<br>
    ${measure_column_name}<br>
    ${measure_column_name}_${aggregate_name}<br>
</blockquote>
<p>
and Mondrian attempts to match a candidate aggregate table's
column names against these as it iterators over a fact table's measures.
</p>
<p>
A grouping of 
<code>
FactCountMatch
</code>,
<code>
ForeignKeyMatch
</code>,
<code>
TableMatcher
</code>,
<code>
LevelMap
</code>,
and
<code>
MeasureMap
</code>
make up a
<code>
AggRule
</code>
element, a rule set.
Each
<code>
AggRule
</code>
has a 
<code>
tag
</code>
attribute which is a unique identifier for the rule.
There can be multiple
<code>
AggRule
</code>
elements in the outer
<code>
AggRules
</code>
element.
Each 
<code>
AggRule
</code>
having its own
<code>
tag
</code>
attribute.
When Mondrian runs, it selects (via the 
<code>
mondrian.rolap.aggregates.rule.tag
</code>
property) which rule set to use.
</p>
<p>
One last wrinkle, within a 
<code>
AggRule
</code>
the
<code>
FactCountMatch
</code>,
<code>
ForeignKeyMatch
</code>,
<code>
TableMatcher
</code>,
<code>
LevelMap
</code>,
and
<code>
MeasureMap
</code>
child elements can be either defined explicitly within the 
<code>
AggRule
</code>
element or by reference
<code>
FactCountMatchRef
</code>,
<code>
ForeignKeyMatchRef
</code>,
<code>
TableMatcherRef
</code>,
<code>
LevelMapRef
</code>,
and
<code>
MeasureMapRef
</code>
The references are defined as child elements of the top level
<code>
AggRules
</code>
element. With references the same rule element
can be used by more than one
<code>
AggRule
</code>
(code reuse).
</p>
<p>
Below is an example of a default rule set with rather different matching
rules.
</p>
<blockquote>
<pre>
&lt;AggRules tag="your_mamas_dot_com"&gt;
  &lt;AggRule tag="default" &gt;
    &lt;FactCountMatch id="fca" factCountName="FACT_TABLE_COUNT"
      charcase="exact" /&gt;
    &lt;ForeignKeyMatch id="fka" pretemplate="agg_" /&gt;
    &lt;TableMatch id="ta" pretemplate="agg_" posttemplate="_.+"/&gt;
    &lt;LevelMap id="lxx" &gt;
      &lt;Regex id="logical" charcase="ignore" space="_" dot="_"&gt;
          ${hierarchy_name}_${level_name}
      &lt;/Regex&gt;
      &lt;Regex id="mixed" charcase="ignore" &gt;
          ${hierarchy_name}_${level_name}_${level_column_name}
      &lt;/Regex&gt;
      &lt;Regex id="mixed" charcase="ignore" &gt;
          ${hierarchy_name}_${level_column_name}
      &lt;/Regex&gt;
      &lt;Regex id="usage" charcase="exact" &gt;
          ${usage_prefix}${level_column_name}
      &lt;/Regex&gt;
      &lt;Regex id="physical" charcase="exact" &gt;
          ${level_column_name}_.+
      &lt;/Regex&gt;
    &lt;/LevelMap&gt;
    &lt;MeasureMap id="mxx" &gt;
      &lt;Regex id="one" charcase="lower" &gt;
          ${measure_name}(_${measure_column_name}(_${aggregate_name})?)?
      &lt;/Regex&gt;
      &lt;Regex id="two" charcase="exact" &gt;
        ${measure_column_name}(_${aggregate_name})?
      &lt;/Regex&gt;
    &lt;/MeasureMap&gt;
  &lt;/AggRule&gt;
&lt;/AggRules&gt;
</pre>
</blockquote>
<p>
First, all fact count columns must be called
<code>
FACT_TABLE_COUNT
</code>
exactly, no ignoring case.
Next, foreign key columns match the regular expression
</p>
<blockquote>
    agg_${foreign_key_name}
</blockquote>
<p>
that is, the fact table foreign key column name with "agg_" prepened such
as 
<code>
agg_time_id
</code>.
The aggregate table names match the regular expression
</p>
<blockquote>
    agg_${fact_table_name}_.+
</blockquote>
<p>
For the FoodMart 
<code>
sales_fact_1997
</code>
fact table, an aggregate could be named,
</p>
<blockquote>
    agg_sales_fact_1997_01<br>
    agg_sales_fact_1997_lost_time_id<br>
    agg_sales_fact_1997_top<br>
</blockquote>
<p>
If the hierarchy, level and level column names were:
</p>
<blockquote>
    hierarchy_name="Sales Location"<br>
    level_name="State"<br>
    level_column_name="state_location"<br>
    usage_prefix=null<br>
</blockquote>
<p>
then the following aggregate table column names would be 
recognizing as level column names:
</p>
<blockquote>
    SALES_LOCATION_STATE<br>
    Sales_Location_State_state_location<br>
    state_location_level.<br>
</blockquote>
<p>
If in the schema file the DimensionUsage for the hierarchy had a
usagePrefix attribute,
</p>
<blockquote>